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.

Slides:



Advertisements
Similar presentations
1.Quality-“a characteristic or attribute of something.” As an attribute of an item, quality refers to measurable characteristics— things we are able to.
Advertisements

Software Quality Assurance Plan
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Chapter 4 Quality Assurance in Context
More CMM Part Two : Details.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 1 1 Disciplined Software Engineering Lecture #7 Software Engineering.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
1 Software Testing and Quality Assurance Lecture 2 Software Verification & Validation.
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.
 QUALITY ASSURANCE:  QA is defined as a procedure or set of procedures intended to ensure that a product or service under development (before work is.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Verification and Validation
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
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 Chapter Software Quality  How can you tell if software has high quality?  How can we measure the quality of software?  How.
CCSB223/SAD/CHAPTER141 Chapter 14 Implementing and Maintaining the System.
Introduction to Software Quality Assurance (SQA)
Software Inspections and Walkthroughs By. Adnan khan.
Software Quality Assurance
S oftware Q uality A ssurance Part One Reviews and Inspections.
Software Quality Assurance Activities
Chapter 14: Inspection  Basic Concept and Generic Process  Fagan Inspection  Other Inspection and Related Activities.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Formal and Informal Peer Reviews
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Software System Engineering: A tutorial
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
程建群 博士 (Dr. Jason Cheng) 年 03 月 Software Engineering Part 06.
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
Disciplined Software Engineering Lecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
Jump to first page (C) 1998, Arun Lakhotia 1 Quality Assurance: Reviews and Walkthroughs Arun Lakhotia University of Southwestern Louisiana Po Box
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Copyright © 1994 Carnegie Mellon University Disciplined Software Engineering - Lecture 7 1 Design and Code Reviews - Overview What are design and code.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Implementation Phase CS4311 – Spring 2008 References: Shach, Object Oriented and Classical Software Engineering E. Braude, Software Engineering, an Object-Oriented.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
Software Quality Assurance and Testing Fazal Rehman Shamil.
VERIFICATION AND VALIDATION TECHNIQUES. The goals of verification and validation activities are to assess and improve the quality of the work products.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
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.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
1 Software Testing and Quality Assurance Motivation and Review of Software Verification & Validation (2)
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Software Quality Control and Quality Assurance: Introduction
CIS 375 Bruce R. Maxim UM-Dearborn
Software Configuration Management (SCM)
Software Quality Assurance
Air Carrier Continuing Analysis and Surveillance System (CASS)
Chapter 14: Inspection Basic Concept and Generic Process
Peer Reviews 11/21/2018.
QA Reviews Lecture # 6.
Software Reviews.
Testing, Inspection, Walkthrough
Presentation transcript:

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 need for QA and removal can be supported by inspection Various software artifacts available at the end of the Software development can only be inspected and not tested. Various software artifacts available at the end of the Software development can only be inspected and not tested. Different degrees of inspection Different degrees of inspection

Generic inspection process Planning and preparation Planning and preparation Goals and objectives Software artifacts to be inspected Who are performing inspections Who else need to be involved What are the process, techniques and follow-up activities

Inspection or collection Corresponds to the execution of QA activities Corresponds to the execution of QA activities Inspection meeting Inspection meeting Focus on identifying faults in the software artifacts Focus on identifying faults in the software artifacts Record the inspection results Record the inspection results

Correction and follow up Faults to be corrected Faults to be corrected Design or code owner need to fix the design or code Design or code owner need to fix the design or code Follow up activity to verify the fix Follow up activity to verify the fix Close interaction between inspection technique and the inspection process. Close interaction between inspection technique and the inspection process.

Informal desk checks, reviews, and walkthroughs Informal desk checks refers to informal check and inspection of technical documents produced by oneself. Informal desk checks refers to informal check and inspection of technical documents produced by oneself. Reviews refer to informal check or inspection of technical documents produced by someone else. Reviews refer to informal check or inspection of technical documents produced by someone else. Focus should be on logical and technical problems Focus should be on logical and technical problems

Defect Detection Techniques Checklist based defect detection Checklist based defect detection Checklist for major features and functions Checklist for major features and functions In requirement and specification inspections. In requirement and specification inspections. Component in design inspections, data structures and data definitions. Component in design inspections, data structures and data definitions. Property based checklist Property based checklist Checklist for coding style and standard, conformance to development methodologies, coupling between different modules Checklist for coding style and standard, conformance to development methodologies, coupling between different modules

INSPECTIONS Quality improvement & cost reduction technique. Quality improvement & cost reduction technique. Design & code inspections Design & code inspections Cost effectiveness of the program Cost effectiveness of the program Fundamental Process and the requirement for inspections Fundamental Process and the requirement for inspections

INSPECTION PROCESS Primary Purpose: Primary Purpose: 1.Identify potential defects during preparation & validate. 2.Validate the fact that identified items are actual defects. 3.Record the existence of the defect. 4.Provide the record to the developer to use in making fixes

SECONDARY PURPOSE 1.To provide traceability of requirements to design. 2.To provide sound base for the next phase 3 To Increase programming quality. 4.To Increase product quality. 5.Lower life cycle cost. 6.To provide feel of program maintainability

INSPECTION PHASES Planning The moderator is responsible for the entire inspection process for the software product. 1.Assure the identification of team 2.Adequate preparation 3.Avaialability of material to be inspected and conformance to standard 4.Preparation of check list

PLANNING Determine the need for an overview Determine the need for an overview Place for inspection meeting Place for inspection meeting Schedule the time & place Schedule the time & place Serve a notice to all parties involved Serve a notice to all parties involved Assign the role of reader to a selected member of the inspection team Assign the role of reader to a selected member of the inspection team

PREPARATION At least five working days before the start of inspection meeting, the material must be provided. At least five working days before the start of inspection meeting, the material must be provided. Must not go exceed two hours. Must not go exceed two hours. Defects are recorded on inspection –defect log form. Defects are recorded on inspection –defect log form.

INSPECTION MEETING Defects are discussed and recorded. The moderator is responsible for proper conduct of the meeting. Verification of defects Verification of defects Defects are recorded by each team member, the defect type is noted & at the end of the inspection defects are counted. Defects are recorded by each team member, the defect type is noted & at the end of the inspection defects are counted. Must be limited to finding defects Must be limited to finding defects

REWORK The author correct the defects. The author correct the defects. Corrections are verified. Corrections are verified. Must discuss the corrections with moderator. Must discuss the corrections with moderator. May be recommended for further inspection. May be recommended for further inspection.

INSPECTION TYPES HIGH LEVEL DESIGN INSPECTION HIGH LEVEL DESIGN INSPECTION LOW LEEVEL DESIGN INSPECTION LOW LEEVEL DESIGN INSPECTION CODE INSPECTION CODE INSPECTION

HIGH LEVEL DESIGN INSPECTION During the high level design phase, overall design for a module function is produced. During the high level design phase, overall design for a module function is produced. For each function, the design specification will provide: For each function, the design specification will provide: 1. The source of design (new, other contract, etc) 2. A graphical presentation of the function allocation to hardware resources 3. A graphical presentation of function flow 4. A description of scheduling, timing, and synchornization 5. A definition of interfaces 6. The process of decomposition

HIGH LEVEL DESIGN INSPECTION 7. The design definition as follows: Retained modules: reference to the existing preliminary (i.e. high level) design specification, as applicable Retained modules: reference to the existing preliminary (i.e. high level) design specification, as applicable Modified modules: reference to the existing preliminary (i.e high level) design specification, where applicable, and a narrative description of the changes Modified modules: reference to the existing preliminary (i.e high level) design specification, where applicable, and a narrative description of the changes New modules: high level description of the interfaces and processing. New modules: high level description of the interfaces and processing.

LOW LEVEL DESIGN Low level reflects back on the overall design objectives. Key objectives considered in designing software are: Low level reflects back on the overall design objectives. Key objectives considered in designing software are: 1. Accuracy with high performance 2. Reliability and fault tolerance, enabling the system to continue to perform in the event of hardware intermittent failure or other unexpected occurences; 3. Flexibility to accommodate change and growth; 4. Easy testability and 5. That it be readily maintainable

KEY FEATURES OF LOW LEVEL DESIGN Detail design module is developed and inspections are held for all modules which meet any of the following criteria: 1. New module development; 2. Any change to the external interface or function of an existing module; 3. A structural change in an existing module; and 4. A 40 percent or greater change in the source lines of code in an existing module. This % presumes that the size requirements as specified in the military standards are adhered to. In the case of unrestricted module size, where the module is large, this percentage criterion may not be proper.

CODE INSPECTIONS A code inspection is held for all new codes or code from another task being modified to meet the requirements of the new task or contract. The code inspection is not performed until after there has been an error free compilation.

CODE INSPECTION CODE INSPECTION It serves the following purpose: 1. Verification that the code conforms to the requirements specification, design specification and interface design specification requirements for operational software. 2. Confirmation that the design has been correctly converted to the target language. 3. Early audit of code quality by the software developer’s peers. 4. Early detection of errors. 5. Verification that the code meets level to level module interface requirements.

INSPECTION DEFECT TYPES Design defect Design defect Logic defect Logic defect Syntax defect Syntax defect Standards defect Standards defect Data defect Data defect Interface defect Interface defect Return code/ message defect Return code/ message defect Requirements change defect Requirements change defect Performance improvement defect Performance improvement defect

Inspection Prerequisites A team of technically competent,trained inspectors A team of technically competent,trained inspectors A trained moderator A trained moderator Proper planning and distribution of material Proper planning and distribution of material Full preparation prior to the inspection meeting Full preparation prior to the inspection meeting Completely design or cleanly compiled code Completely design or cleanly compiled code Updated resource requirements Updated resource requirements

Responsibilities of the moderator Complete The SQE training course Complete The SQE training course Check the entry criteria Check the entry criteria Preview the material for conformance to standards Preview the material for conformance to standards Team size and mix is proper Team size and mix is proper Assure there are at least five days of preparation Assure there are at least five days of preparation

During inspection/After inspection Adequate attendance Adequate attendance Adequate preparation Adequate preparation Lead the inspection meeting Lead the inspection meeting Log defects Log defects Require re-inspection for major defects, Require re-inspection for major defects, specification changes, or greater then 50 defects per 1000 LOC

After Inspection Review results with the author Review results with the author Provide the manager with an estimate of rework completion data Provide the manager with an estimate of rework completion data Eliminate duplicate defect log entries and send summary to SQE Eliminate duplicate defect log entries and send summary to SQE Verify correction of all defect log entries Verify correction of all defect log entries Add completion notice and send copy to SQE Add completion notice and send copy to SQE

Responsibilities of Inspectors Attend the SQE training classes Attend the SQE training classes Thoroughly all material Thoroughly all material Assure understanding of function, consult author if necessary Assure understanding of function, consult author if necessary Record detected defects on inspection defect log form prior to inspection Record detected defects on inspection defect log form prior to inspection

Responsibilities of Manager Establish schedule Establish schedule Meet with moderator and author Meet with moderator and author Monitor individual inspection time Monitor individual inspection time Review SQE defect summary for defect trends and perform defect trends analysis Review SQE defect summary for defect trends and perform defect trends analysis