© USC-CSE Feb 6. 20011 Keun Lee ( & Sunita Chulani COQUALMO and Orthogonal Defect.

Slides:



Advertisements
Similar presentations
Software Quality Assurance Plan
Advertisements

COMP8130 and 4130Adrian Marshall Verification & Validation INSPECTIONS Adrian Marshall.
CS 325: Software Engineering January 13, 2015 Introduction Defining Software Engineering SWE vs. CS Software Life-Cycle Software Processes Waterfall Process.
More CMM Part Two : Details.
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003.
Stepan Potiyenko ISS Sr.SW Developer.
University of Southern California Center for Software Engineering CSE USC COSYSMO: Constructive Systems Engineering Cost Model Barry Boehm, USC CSE Annual.
Week 7: Requirements validation Structured walkthroughs Why have walkthroughs When to have walkthroughs Who participates What procedures are helpful Thoughtless.
January 20, 2002ECEN5033 University of Colorado, Testing OO Software Part Two 1 Testing Object-Oriented Software – Testing Models Software Engineering.
University of Southern California Center for Software Engineering CSE USC ©USC-CSE 10/23/01 1 COSYSMO Portion The COCOMO II Suite of Software Cost Estimation.
University of Southern California Center for Software Engineering C S E USC 09/15/05©USC-CSE1 Barry Boehm, USC Motorola Quality Workshop September 15,
University of Southern California Center for Systems and Software Engineering ©USC-CSSE1 Ray Madachy, Barry Boehm USC Center for Systems and Software Engineering.
RIT Software Engineering
SE 450 Software Processes & Product Metrics 1 Defect Removal.
University of Southern California Center for Software Engineering CSE USC USC-CSE Annual Research Review COQUALMO Update John D. Powell March 11, 2002.
CSE USC Fraunhofer USA Center for Experimental Software Engineering, Maryland February Empiricism in Software Engineering Empiricism:
Copyright USC-CSSE 1 Quality Management – Lessons of COQUALMO (COnstructive QUALity MOdel) A Software Defect Density Prediction Model AWBrown.
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 18-1 Accounting Information Systems 9 th Edition Marshall.
© USC-CSE1 Determine How Much Dependability is Enough: A Value-Based Approach LiGuo Huang, Barry Boehm University of Southern California.
Software Quality Assurance For Software Engineering && Architecture and Design.
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Case Studies Instructor Paulo Alencar.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Prof. Mohamed Batouche Quality Control.
Effective Methods for Software and Systems Integration
Extreme Programming Software Development Written by Sanjay Kumar.
Software Inspections and Walkthroughs By. Adnan khan.
1 Software Quality Engineering CS410 Class 5 Seven Basic Quality Tools.
CLEANROOM SOFTWARE ENGINEERING.
Applying the Inspection Process. What Software Artifacts Are Candidates for Inspection? Software Requirements Software Designs Code Test Plans.
S oftware Q uality A ssurance Part One Reviews and Inspections.
Chapter 14: Inspection  Basic Concept and Generic Process  Fagan Inspection  Other Inspection and Related 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.
Software Defect Prevention Using Orthogonal Defect Classification
Software Quality Assurance Lecture #2 By: Faraz Ahmed.
University of Southern California Center for Systems and Software Engineering 10/30/2009 © 2009 USC CSSE1 July 2008©USC-CSSE1 The Incremental Commitment.
This chapter is extracted from Sommerville’s slides. Text book chapter
1 Pop Quiz What is an Orthogonal Defect? Which is more precise: predictive models or management models? Why? Essay: Why are metrics and models an important.
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
© USC-CSE 2001 Oct Constructive Quality Model – Orthogonal Defect Classification (COQUALMO-ODC) Model Keun Lee (
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract.
This chapter is extracted from Sommerville’s slides. Textbook chapter
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Chapter 19 Verification and Validation.
(1) Introduction to Software Review Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii.
Anton Krbaťa Ján Budáč  Verification: "Are we building the product right ?„  Validation: "Are we building the right product ?"
Verification and Validation Assuring that a software system meets a user's needs.
Pair Development Framework Monvorath (Molly) Phongpaibul.
University of Southern California Center for SoftwareEngineering Reliable Software Research and Technology Transition Barry Boehm, USC NASA IT Workshop.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
CSI 1340 Introduction to Computer Science II Chapter 1 Software Engineering Principles.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
1 Software Quality Engineering. 2 Quality Management Models –Tools for helping to monitor and manage the quality of software when it is under development.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
This chapter is extracted from Sommerville’s slides. Textbook chapter 22 1 Chapter 8 Validation and Verification 1.
Project Planning Goal 1 - Estimates are documented for use in tracking and planning project. Goal 2 - Project Activities and commitments planned and documented.
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Software Quality Assurance
CSC 480 Software Engineering
IEEE Std 1074: Standard for Software Lifecycle
12 Steps to Useful Software Metrics
Constructive Cost Model
Software Quality Assurance
Chapter 13 Quality Management
Quality Management, Peer Review, & Architecture Review Board
Peer Reviews A. Winsor Brown Jan. 13, 2010
Testing, Inspection, Walkthrough
Presentation transcript:

© USC-CSE Feb Keun Lee ( & Sunita Chulani COQUALMO and Orthogonal Defect Classification(ODC)

© USC-CSE Feb Current COQUALMO Model - Results and Challenges COQUALMO – ODC Research Approach Example Results Issues and Research Plans COQUALMO and Orthogonal Defect Classification(ODC)

© USC-CSE Feb COCOMO II Current COQUALMO System COQUALMO Defect Introduction Model Defect Removal Model Software platform, Project, product and personnel attributes Software Size Estimate Defect removal profile levels Automation, Reviews, Testing Software development effort, cost and schedule estimate Number of residual defects Defect density per unit of size

© USC-CSE Feb Partion of COQUALMO Rating Scale Very LowLowNominalHighVery HighExtra High Automated Analysis Simple compiler syntax checking Basic compiler capabilities Compiler extension Basic req. and design consistency Intermediate- level module Simple req./design More elaborate req./design Basic dist- processing Formalized specification, verification. Advanced dist- processing Peer Reviews No peer review Ad-hoc informal walk-through Well-defined preparation, review, minimal follow-up Formal review roles and Well-trained people and basic checklist Root cause analysis, formal follow Using historical data Extensive review checklist Statistical control Execution Testing and Tools No testingAd-hoc test and debug Basic test Test criteria based on checklist Well-defined test seq. and basic test coverage tool system More advance test tools, preparation. Dist- monitoring Highly advanced tools, model- based test COCOMO II p.263

© USC-CSE Feb COQUALMO Defect Removal Estimates - Nominal Defect Introduction Rates Delivered Defects / KSLOC Composite Defect Removal Rating

© USC-CSE Feb Multiplicative Defect Removal Model - Example : Code Defects; High Ratings Analysis : 0.7 of defects remaining Reviews : 0.4 of defects remaining Testing : 0.31 of defects remaining Together : (0.7)(0.4)(0.31) = 0.09 of defects remaining How valid is this? - All catch same defects : 0.31 of defects remaining - Mostly catch different defects : ~0.01 of defects remaining

© USC-CSE Feb Example UMD-USC CeBASE Data Comparisons “Under specified conditions, …” Peer reviews are more effective than functional testing for faults of omission and incorrect specification(UMD, USC) Functional testing is more effective than reviews for faults concerning numerical approximations and control flow(UMD,USC) Both are about equally effective for results concerning typos, algorithms, and incorrect logic(UMD,USC)

© USC-CSE Feb ODC Data Attractive for Extending COQUALMO - IBM Results (Chillarege, 1996)

© USC-CSE Feb COQUALMO Extension Research Approach Extend COQUALMO to cover major ODC categories Collaborate with industry ODC users - IBM, Motorola underway - Two more sources being explored Obtain first-land experience on USC digital library projects - Completed IBM ODC training - Initial front-end data collection and analysis

© USC-CSE Feb Artifacts - Operational Concept, Requirements, Software Architecture documents Activities - Perspective-based Fagan inspections Triggers - Environment or condition that causes defect Digital Library Analysis to Date - in ODC terms

© USC-CSE Feb Front End (Information Development) Triggers 1.Clarity – confusing or difficulty to understand information. 2.Style – inappropriate or difficulty to understand the manner of expression 3.Accuracy – incorrect information 4.Task Orientation - inappropriate presentation to perform task 5.Organization – relationship between parts is not conveyed 6.Completeness – missing information. 7.Consistency – the expression manner is not displayed in a consist manner

© USC-CSE Feb Initial Digital Library Project ODC Analysis - Trigger percentage Distribution by Team

© USC-CSE Feb Initial Digital Library Project ODC Analysis - Number of Triggers Defects by Team

© USC-CSE Feb Understand anomalies in Digital Library Data - Number of Team 22 defects - Team 4 completeness defects - Due to differences in artifacts or procedures? Continue Digital Library ODC collection & analysis - Detailed Design, code, test Obtain, analyze industry ODC data - Looking for more sources of ODC Data Issues and Research Plans