1 FY2001 CENTER SOFTWARE INITIATIVE PROPOSAL (CSIP) for the NASA Independent Verification and Validation Facility COTR: Kenneth McGill PI: Nancy Eickelmann.

Slides:



Advertisements
Similar presentations
The ROI of Testing Presented By: Shaun Bradshaw Questcon Technologies The ROI of Testing Presented By: Shaun Bradshaw Questcon Technologies.
Advertisements

Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
More CMM Part Two : Details.
1 State of Michigan Achieving Software Process Improvement with Capability Maturity Model (CMM)
CMMI Overview Dr. Korson Software Engineering. 2 Immature organizations can be successful on occasion, but ultimately run into difficulties because –Success.
Stepan Potiyenko ISS Sr.SW Developer.
Overview Lesson 10,11 - Software Quality Assurance
School of Computing, Dublin Institute of Technology.
OHT 7.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software development methodologies: - The software development life cycle.
1 H. Brief Orientation on aspects of Quality What is Quality? –Various “gurus” have proposed different ideas. One of the most well known was Philip Crosby.
The Analyst as a Project Manager
OHT 7.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software development methodologies: - The software development life cycle.
Civil Government Services Group 1 Return on Investment of Independent Verification and Validation: Indirect Benefits James B. Dabney, Gary Barber, Don.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
© 2008 Prentice Hall11-1 Introduction to Project Management Chapter 11 Managing Project Execution Information Systems Project Management: A Process and.
Project Execution.
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Capability Maturity Model
Quality of Information systems. Quality Quality is the degree on which a product satifies the requirements Quality management requires that : that requirements.
S/W Project Management
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
SQA Architecture Software Quality By: MSMZ.
Nancy S. Eickelmann, PhD Motorola Labs 1303 E. Algonquin Rd. Annex-2 Schaumburg, IL Phone: (847) Fax: (847)
Software Inspections and Walkthroughs By. Adnan khan.
July 18, 2001 Mission Success Begins With Safety Quality Leadership Forum Software Quality Assurance at GSFC Dr. Linda H. Rosenberg Chief Scientist for.
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
Process Assessment Motivation SEI Capability Maturity Model
N By: Md Rezaul Huda Reza n
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.
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
Unit 8 Syllabus Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
Don’t Just “Test”… Validate!!
Analyze Opportunity Part 1
SQA System Overview Chapter 4. Where we have been so far, Where we are going Where do software errors come from? What is quality? How can quality be measured?
Quality Control Project Management Unit Credit Value : 4 Essential
S Q A.
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
IT Requirements Management Balancing Needs and Expectations.
Lecture 11 Managing Project Execution. Project Execution The phase of a project in which work towards direct achievement of the project’s objectives and.
Software process improvement Framework for SPI SPI support groups, maturity and immaturity models Assessment and gap analysis Education and training Selection.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Acquiring Information Systems and Applications
Georgia Institute of Technology CS 4320 Fall 2003.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Telerik Software Academy Software Quality Assurance.
Software Engineering - I
CSE SW Metrics and Quality Engineering Copyright © , Dennis J. Frailey, All Rights Reserved CSE8314M10 8/20/2001Slide 1 SMU CSE 8314 /
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
Computing and SE II Chapter 15: Software Process Management Er-Yu Ding Software Institute, NJU.
Software Engineering Lecture 8: Quality Assurance.
Project Planning Goal 1 - Estimates are documented for use in tracking and planning project. Goal 2 - Project Activities and commitments planned and documented.
Multitude of source of errors - various style of source of errors will affect the SQA components * The environment in which software development & maintenance.
Cost of Poor Quality Cost of Poor Quality.
Software Quality Control and Quality Assurance: Introduction
Systems Analysis and Design in a Changing World, 4th Edition
Software Verification and Validation
Auditing Information Technology
د. حنان الداقيز خريف /28/2016 Software Quality Assurance ضمان جودة البرمجيات ITSE421 5 – The components of the SQA.
Quality Measurable characteristic Cyclomatic complexity Cohesion
Software Engineering I
Capability Maturity Model
Chapter # 1 Overview of Software Quality Assurance
Integrating quality activities in
Capability Maturity Model
Requirements Development in CMMI
Presentation transcript:

1 FY2001 CENTER SOFTWARE INITIATIVE PROPOSAL (CSIP) for the NASA Independent Verification and Validation Facility COTR: Kenneth McGill PI: Nancy Eickelmann Contract #S G September 4, 2002 Developing Risk-Based Financial Analysis Tools and Techniques to Aid IV&V Decision-Making

2 Agenda Why we need ASK IVEY Consequences and Likelihood of Failure IV&V Yield Probability of IV&V Yield: Min, Max, Most Likely ROI and Magnitude of Return of IV&V What ASK IVEY can do

3 Why we need ASK IVEY NASA program managers are asked to quantify the ROI and evaluate the cost/benefit of applying IV&V technologies. This is a prediction of future events based on decisions and actions taken in the present. A point estimate is likely to be inaccurate, whereas a probability of yield has a history of providing a scope of potential yield and an extent of likelihood of expected yield.

4 Calculating ROI a Financial Analysis Prompt Map Yes 1 A Financial Analysis Process Map Create development cost framework: Total Cost COQ COPQ ? IV&V and IA analysis complete. Level of IV&V or IA designated Create certification cost framework 23 Apply Financial models for monetary quanitification Create probability of yield structure 4 A STOP No

5 Consequences of Failure NPG 2820 IV&V Criteria

6 Likelihood of Failure

7 IV&V YIELD Ultimately, the yield of an IV&V program is based upon the difference between the net resource flow with IV&V and without IV&V. If the resources saved (e.g., reduced rework) or returns gained (e.g., improved customer satisfaction or increased safety) are greater than the resources consumed to save/gain these resources, we have a net benefit. Should the resources saved be less than the resources consumed, we have a net cost.

8 Cost of Poor Quality Defect Leakage –If discovered internally defect management rework retesting –If discovered externally technical support complaint investigation defect notification

9 Stephen Knox “Modeling the Cost of Software Quality,” Digital Technical Journal, (Fall 1993)

10 Raytheon Cost of Poor Quality Haley and Dion

11 How Process Maturity Levels Affect IV&V LEVEL 1 INITIAL UNPREDICTABLE & POORLY CONTROLLED LEVEL 2 REPEATABLE CAN REPEAT PREVIOUSLY MASTERED TASKS LEVEL 3 DEFINED PROCESS CHARACTERIZED, FAIRLY WELL UNDERSTOOD LEVEL 4 MANAGED PROCESS MEASURED AND CONTROLLED LEVEL 5 OPTIMIZED FOCUS ON PROCESS IMPROVEMENT KEY PROBLEMS: CONFIG. MGMT. PROJECT MGMT. SOFTWARE QA PROJECT PLANNING EASTIMATING COST SCHEDULE KEY PROBLEMS: PROPER TRAINING DEVELOPMENT OF PRACTICE & PROCEDURES STANDARDS ORGANIZATION KEY PROBLEMS: ACCURATE PROJECT MEASUREMENT OBJECTIVE PROCESS ANALYSIS QUANTITATIVE QUALITY PLANS PRIORITIES: - DECIDING WHAT TO IMPROVE FIRST - BALANCING THE PROCESS AND THE ORGANIZATION KEY PROBLEMS: CHANGING TECHNOLOGY PROBLEM ANALYSIS PROBLEM PREVENTION ORGANIZATIONAL OPTIMIZATION KEY PROBLEMS: STILL HUMAN INTENSIVE PROCESS DIFFICULT TO MAINTAIN OPTIMUM ORGANIZATION DIFFICULT TO MAINTAIN TOOLS & PRACTICES AT STATE OF THE ART IV&V SOMEWHAT UNPREDICTABLE UNABLE TO ESTIMATE NON-TECH % IV&V NON-TECH UP TO 25% NON-TECH UP TO 15% NON-TECH UP TO 6-8% NON-TECH UP TO 3-4% MATURITY

12 Cost of Leakage Grows Over Time Relative cost of fixing a problem found in design/coding, testing, or after release are: –1:20:82 (Remus, 1983) –1:13:92 (Kan, 1989) –10:100:1000 (Coyle, 1999)

13 Cost of Rework in Each Phase Rework product design = leakage requirements * cost-to-fix nominal * 10 Rework programming = leakage requirements * cost-to-fix nominal * 100 +leakage design * cost-to-fix nominal * 10 Rework integration = leakage requirements * cost-to-fix nominal * leakage design * cost-to-fix nominal * 100 +leakage programming * cost-to-fix nominal * 10 Rework deployment = leakage requirements * cost-to-fix nominal * leakage design * cost-to-fix nominal * leakage programming * cost-to-fix nominal * 100

14 Rework at Deployment Tremendous cost rework plus –product recall –technical support –field visits –cost factor may be over 10,000

15 Leakage: An Example Rework product design = 49 r * cost-to-fix nominal * 10 = 490 Rework programming = 39 r * cost-to-fix nominal * 100 = 3, d * cost-to-fix nominal * 10 = 1,130 Rework integration = 26 r * cost-to-fix nominal * 1000 = 26, d * cost-to-fix nominal * 100 = 4, p * cost-to-fix nominal * 10 = 4,180 Rework deployment = 8 r * cost-to-fix nominal * = 80, d * cost-to-fix nominal * 1000 = 16, p * cost-to-fix nominal * 100 = 5,600142,200

16 CMM Maturity and Leakage There is some evidence to suggest organizations with increased maturity have reduced rework costs Knox: Percent of Budget to Rework: –Level 1: 55% –Level 2: 45% –Level 3: 35% –Level 4: 20% –Level 5: 6%

17 IV&V and Defect Leakage Application of IV&V can reduce leakage to subsequent phases The goal of the financial model is to propose a range of potential savings Specific parameters will need to be established empirically

18 Timing of benefits for IV&V Full In-Phase IV&V –prevention of errors starting at requirements - can potentially bar any errors from leaking through Partial IV&V –prevention of errors at point of insertion - no errors from this phase will leak Endgame IV&V –discovery of errors at the end of development - can potentially bar any errors from leaking to deployment Audit Level IV&V

19 Rework and Return from IV&V By Maturity Level

20 Components to Return on Investment Cost of IV&V Expected Return –cost savings - measured as hours of rework Likelihood of Returns –how effective is the organization at minimizing rework? –how effective will IV&V be?

21 Independence… An organization independent from the developers study the artifacts of software production [IEEE Std ]. This requires: -Technical independence. Members of the IV&V team may not be personnel involved in the development of the software. -.Managerial independence. The responsibility for IV&V belongs to an organization outside the contractor and program organizations that develop the software. -Financial independence. Control of the IV&V budget is retained in an organization outside the contractor and program organization that develop the software. IV&V is often perceived as testing the code after the development is completed …..NASA IV&V is full life cycle activities

22 IV&V is NOT SQA IV&V is a full life cycle set of acivities that are applied to defect prevention, defect detection, and certification. NASA IV&V conforms to IEEE Standard IV&V and Software Quality Assurance (SQA) are not redundant activities. SQA as defined by DOD-Std 2168 defines 10 activities of SQA that are complemented by IV&V activities. There are 32 types of activities conducted by IV&V, of these 32, 22 are unique to IV&V and 10 are complemented by SQA.

23 Ask Ivey Prototype What ASK IVEY can do…

24 Ask Ivey Input Screen

25 Ask Ivey Pull Down Menu

26 Ask Ivey Numeric Entry

27 Ask Ivey On-Line Report

28 Ask Ivey Printed Report

29 Ask Ivey On-Line Help

30 Questions? Ask Ivey…