1 Fault-Based Analysis: Improving IV&V Through Requirements Risk Reduction '02 Jane Hayes Rama Bireddy D.N. American SAIC Department of Computer Science.

Slides:



Advertisements
Similar presentations
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Advertisements

Ask Pete Acquired Software Knowledge Project - Estimation- Tool - Effort Presented to the NASA OSMA SAS ‘01 NASA IV&V Facility September 5-7, 2001 Tim.
SBSE Course 3. EA applications to SE Analysis Design Implementation Testing Reference: Evolutionary Computing in Search-Based Software Engineering Leo.
DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Phase III – Validation Thomas Howard Chris Pierce.
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Stepan Potiyenko ISS Sr.SW Developer.
So far.. We have covered a) Requirements gathering: observation & interview. b) Requirements specification. c) Requirements validation. d) Design/paper.
Overview of GIS projects Geog 463 March 29, 2006.
Software Metrics II Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
Computer Science Department Program Improvement Plan December 3, 2004.
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
PSU CS 106 Computing Fundamentals II Product Life Cycle & SW Product Life Cycle HM 9/3/2007.
 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.
SQA Architecture Software Quality.
McGraw-Hill/Irwin © 2013 The McGraw-Hill Companies, Inc., All Rights Reserved. Chapter 9 XBRL.
West Virginia University A Bayesian Approach to Reliability Predication of Component Based Systems H. Singh, V. Cortellessa, B. Cukic, E. Gunel, V. Bharadwaj.
Development plan and quality plan for your Project
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
Chapter 2: Overview of Essentials ISE 443 / ETM 543 Fall 2013.
Issues in Teaching Software Engineering Virendra C. Bhavsar Professor and Director, Advanced Computational Research Laboratory Faculty of Computer Science.
SQA Architecture Software Quality By: MSMZ.
COMPGZ07 Project Management Presentations Graham Collins, UCL
Extreme Programming Software Development Written by Sanjay Kumar.
Ch.4: QA in Context  QA and the overall development context Defect handling/resolution How alternative QA activities fit in process Alternative perspectives:
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Interactive Notebook AP Biology - Zeiher. What are Interactive Notebooks?  Known as IANS  A student note taking process to record information in a personal.
1SAS 03/ GSFC/SATC- NSWC-DD System and Software Reliability Dolores R. Wallace SRS Technologies Software Assurance Technology Center
OSMA2003 Center for Reliability Engineering 1 Integrating Software into PRA Presented by C. Smidts Center for Reliability Engineering University of Maryland.
1PBI_SAS_08_Exec_ShullSeptember 2008MAC-T IVV Dr. Forrest Shull, FCMD Kurt Woodham, L-3 Communications OSMA SAS 08 Infusion of Perspective-Based.
Evaluation of software engineering. Software engineering research : Research in SE aims to achieve two main goals: 1) To increase the knowledge about.
ACCOUNTING INFORMATION SYSTEMS
SOFTWARE PROTOTYPING Anil Kumar.Arikepudi.
TESTING PRINCIPLES BY K.KARTHIKEYAN. PRINCIPLES Principle 1. Testing is the process of exercising a software component using a selected set of test cases,
1 Long Term Monitoring JPSS Algorithm Team Presented by Date.
Software Safety Risk Evaluation Process Yorick Bouma, , Group III.
Software Testing. What is Testing? The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation.
LECTURE IV. o Project HRM include the processes that organize, manage and lead the project team. o The project team is comprised of the people with assigned.
1 Presentation Template: Instructor Comments u The following template presents a guideline for preparing a Six Sigma presentation. An effective presentation.
Scoping GIS projects Geog 469 GIS Workshop. Outline 1.What is a possible scope for a GIS project? 2.What is a methodology for a GIS (project) implementation.
Development of Methodologies for Independent Verification and Validation of Neural Networks NAG OSMA-F001-UNCLASS Methods and Procedures.
1 Chapter 3 1.Quality Management, 2.Software Cost Estimation 3.Process Improvement.
1 EMS Fundamentals An Introduction to the EMS Process Roadmap AASHTO EMS Workshop.
Soil Classification and Survey
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
CPSC 871 John D. McGregor Module 1 Session 4 Requirements Review.
Software Engineering Principles Practical Advice and Steps for Managing Your Project.
Completing the Loop: Linking Software Features to Failures 31 July 2003 Copyright © 2003, Mountain State Information Systems, Inc. All rights reserved.
Software Quality Assurance and Testing Fazal Rehman Shamil.
 “I have to teach the same information skills each year because students do not learn them.”  “I don’t have time to give tests so I do not assess student.
Robust Requirements Tracing Via Internet Tech:Improving an IV&V Technique SAS 2004July 20, 2004 Alex Dekhtyar Jane Hayes Senthil Sundaram Ganapathy Chidambaram.
Contents 1 Description of 1 Description of Initiative Initiative 3 Defining Inspection 3 Defining Inspection Perspectives Perspectives 2 Overview of 2.
Testing and Evaluating Software Solutions Introduction.
Using Bayesian Belief Networks in Assessing Software Architectures Jilles van Gurp & Jan Bosch.
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Chapter 3 of Your Research Project AED 615 Fall 2006 Dr. Franklin.
Copyright 2015, Robert W. Hasker. Classic Model Gathering Requirements Specification Scenarios Sequences Design Architecture Class, state models Implementation.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Managing Qualitative Knowledge in Software Architecture Assesment Jilles van Gurp & Jan Bosch Högskolan Karlskrona/Ronneby in Sweden Department of Software.
Information Technology Project Management, Seventh Edition.
Chapter 5: Software effort estimation
UC Marco Vieira University of Coimbra
The Integrated Food Security Phase Classification in Sudan –Next Steps
Software Verification and Validation
Network Life Cycle Created by Michael Law
Presented to the NASA OSMA SAS ‘01
Life Cycle Models PPT By :Dr. R. Mall.
Baisc Of Software Testing
Summary.
© Oxford University Press All rights reserved.
Presentation transcript:

1 Fault-Based Analysis: Improving IV&V Through Requirements Risk Reduction '02 Jane Hayes Rama Bireddy D.N. American SAIC Department of Computer Science University of Kentucky

2 Outline  Research Objective  Research Approach  Progress to Date  Current Plans  Future Work

3 Research Objective To improve how we focus resources for IV&V of Critical/Catastrophic High-Risk (CCHR) software functions, we use a fault-based analysis method comprised of: a requirements fault taxonomy (Phase I) a method for extending taxonomies (Phase I) a taxonomy of IV&V techniques (Phase I and II) what faults the techniques can detect (Phase II+) a fault-based risk assessment per Class and project (Phase I+) a cost-benefit analysis of technique effectiveness (validated) (Phase II+)

4 Research Approach (Phase I) Task 1 – Select a Known Fault Taxonomy Task 2, 3 – PMR 2,3 (Presentation and Milestone Meeting) Task 4 – Examine NASA-specific requirements faults Task 5 – Build a list of IV&V techniques Task 6 – Adopt or build a method for extending the taxonomy Task 7 –Implement the method to extend the fault taxonomy Task 8,9 - Year-end report and presentation (also PMR 4)

5 Progress to Date NUREG/CR-6316 basis of general taxonomy Literature survey (55 references) resulted in three additions to taxonomy Review of defect data for 3 NASA projects resulted in two additions and re-organization of taxonomy

6 General Taxonomy Taxonomy figure

7 NASA Requirement Faults Have proven difficult to obtain Level of detail varies greatly Have thus far received and examined –IV&V “comments” on requirement problems for 3 projects –Project fault reports related to requirements for 1 project Data very useful, resulted in several changes to fault taxonomy and taxonomy extension/tailoring processes

8 Task 6 Process for extending fault taxonomy split into two parts: Process A and Process B Process A - activities to develop a Class- specific taxonomy Outputs of Process A are inputs to Process B Process B – activities to develop a project- specific taxonomy

9 Processes for Extending Fault Taxonomies High level process

10 Class-Specific Taxonomy Process Process

11 Project-Specific Taxonomy Process Process

12 Current Plans Obtain requirement-related fault reports for additional NASA projects Perform Process A (Class-specific) for classes for which we have data Complete list of IV&V techniques Continue sharing information and soliciting feedback from ST-5 project Prepare final report

13 Future Work (Phase II) Build taxonomy of IV&V techniques Survey literature and determine what techniques have been shown to detect certain types of requirement faults Gather expert opinion to fill in gaps of the technique-to-fault matrix Design experiments to validate some of the technique-to-fault mappings Provide resulting information in an Advanced Risk Reduction Tool (ARRT) friendly format

14 Backup

15 How does this differ from ODC? ODC uses a fixed set of trigger and defect types Our emphasis is on building tailored taxonomies We use historical information about Classes of related projects ODC classification strives to be independent of the specifics of a product or organization

16 How does this differ from ODC? (cont’d) ODC defect types don’t map well to requirements (function, I/f, checking, assignment, algorithm, etc.) We integrate risk analysis in our taxonomy building process Our long-term goals include validated cost-benefit information for fault- technique pairs