Software causes many failures - significant mission risk Hard to quantify effects on system risk of: software defects software development practices software.

Slides:



Advertisements
Similar presentations
PROJECT RISK MANAGEMENT
Advertisements

Chapter 4 Quality Assurance in Context
4.1.5 System Management Background What is in System Management Resource control and scheduling Booting, reconfiguration, defining limits for resource.
PROBLEMSOLUTION TECHNOLOGY Traceability relations between requirements and code are generally derived manually, and must be manually updated when software.
1 Independent Verification and Validation Current Status, Challenges, and Research Opportunities Dan McCaugherty IV&V Program Manager Titan Systems Corporation.
University of Southern California Center for Systems and Software Engineering ©USC-CSSE1 Ray Madachy, Barry Boehm USC Center for Systems and Software Engineering.
(c) 2007 Mauro Pezzè & Michal Young Ch 1, slide 1 Software Test and Analysis in a Nutshell.
SQM - 1DCS - ANULECTURE Software Quality Management Software Quality Management Processes V & V of Critical Software & Systems Ian Hirst.
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
Software Process and Product Metrics
Quality Risk Management ICH Q9 Annex I: Methods & Tools
Civil Government Services Group 1 Return on Investment of Independent Verification and Validation: Indirect Benefits James B. Dabney, Gary Barber, Don.
Architecture, Implementation, and Testing Architecture and Implementation Prescriptive architecture vs. descriptive architecture Prescriptive architecture:
SEG Software Maintenance1 Software Maintenance “The modification of a software product after delivery to correct faults, to improve performance or.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Software Reliability Growth. Three Questions Frequently Asked Just Prior to Release 1.Is this version of software ready for release (however “ready” is.
CSCE 548 Secure Software Development Risk-Based Security Testing.
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
University of Southern California Center for Systems and Software Engineering GQM, GQM+ Supannika Koolmanojwong CSCI577 Spring 2013 (C) USC-CSSE1.
Risk management in Software Engineering T erm Paper By By Praveenkumar Sammita Praveenkumar Sammita CSC532 CSC532.
N By: Md Rezaul Huda Reza n
Presented to President’s Cabinet. INTERNAL CONTROLS are the integration of the activities, plans, attitudes, policies and efforts of the people of an.
Risk Management - the process of identifying and controlling hazards to protect the force.  It’s five steps represent a logical thought process from.
UNIT 9: An Ecosystem Approach to Fisheries Management Plan.
Software testing basic. Main contents  Why is testing necessary?  What is testing?  Test Design techniques  Test level  Test type  How to write.
Analyze Opportunity Part 1
Instructor: Peter Clarke
Teaching material for a course in Software Project Management & Software Engineering – part II.
PowerPoint Presentation for Dennis, Wixom & Tegarden Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
ESA/ESTEC, TEC-QQS August 8, 2005 SAS_05_ESA SW PA R&D_Winzer,Prades Slide 1 Software Product Assurance (PA) R&D Road mapping Activities ESA/ESTEC TEC-QQS.
Software Engineering Lecture # 17
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem Darwish.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Module 4: Systems Development Chapter 12: (IS) Project Management.
What Do We Know about Defect Detection Methods P. Runeson et al.; "What Do We Know about Defect Detection Methods?", IEEE Software, May/June Page(s):
程建群 博士 (Dr. Jason Cheng) 年 03 月 Software Engineering Part 05.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
West Virginia University Towards Practical Software Reliability Assessment for IV&V Projects B. Cukic, E. Gunel, H. Singh, V. Cortellessa Department of.
Optimizing NASA IV&V Benefits Using Simulation Grant Number: NAG David M. Raffo, Ph.D College of Engineering and Computer Science School of Business.
Formulating a Simulation Project Proposal Chapter3.
SOFTWARE PROJECT MANAGEMENT
Institutional affiliation Date.  Security is very important as it keeps your secret from other know.  An insecure network exposes a business to various.
Software Architecture Risk Assessment (SARA) Tool Khader Shaik, Wallid Abdelmoez, Dr. Hanny Ammar Lane Department of Computer Science and Electrical Engineering,
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Accelerated Long Range Traverse (ALERT) Paul Springer Michael Mossey.
University of Southern California Center for Software Engineering CSE USC SCRover Increment 3 and JPL’s DDP Tool USC-CSE Annual Research Review March 16,
R ISK A NALYSIS & M ANAGEMENT. Risk – possibility that an undesirable event (called the risk event) could happen – Involve uncertainty and loss – Events.
1 Overview of Maintenance CPRE 416-Software Evolution and Maintenance-Lecture 3.
Hussein Alhashimi. “If you can’t measure it, you can’t manage it” Tom DeMarco,
TRAC Software for creation of supplier contract risk profile
Completing the Loop: Linking Software Features to Failures 31 July 2003 Copyright © 2003, Mountain State Information Systems, Inc. All rights reserved.
Overview of Socio-cognitive Engineering General requirements Theory of Use Design Concept Contextual Studies Task model Design space System specification.
SAS_05_Contingency_Lutz_Tal1 Contingency Software in Autonomous Systems Robyn Lutz, JPL/Caltech & ISU Doron Tal, USRA at NASA Ames Ann Patterson-Hine,
Probabilistic Risk Assessment and Conceptual Design Bryan C Fuqua – SAIC Diana DeMott – SAIC
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Issue Tracking and Risk Management John D. McGregor Module 10 Session 1 Issue Tracking and Risk.
Toward a New ATM Software Safety Assessment Methodology dott. Francesca Matarese.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
CSCE 548 Secure Software Development Risk-Based Security Testing
Risk Management.
Analysis of Current Maturity Models and Standards
Identify the Risk of Not Doing BA
Safety and Risk.
Failure mode and effect analysis
Auditing Application Controls
Goal, Question, and Metrics
Baisc Of Software Testing
Measurement What is it and why do it? 2/23/2019
A New Concept for Laboratory Quality Management Systems
Presentation transcript:

Software causes many failures - significant mission risk Hard to quantify effects on system risk of: software defects software development practices software verification and validation PROBLEMSOLUTION TECHNOLOGY Analyzing Software Contribution to System Failures Link factors affecting software quality to system failures modes by: 1.Predicting number of defects in software subsystems given software development and V&V decisions 2.Using a fault tree to link software defects to system failures, affecting their probabilities Prototype implementation in the Eclipse software development environment of tool linking: 1.ODC COQUALMO - USC/Ames tool which predicts number of software defects and effectiveness of V&V tools 2.DDP - JPL tool calculates risks, costs and effect of mitigation strategies from user specification of links between system objectives, risks and mitigations In this application, DDP represents system fault tree where some leaf nodes correspond to software defects. DDP derives information from ODC COQUALMO on software defect numbers, type and V&V effectiveness. DDP calculates system failure probability before and after selected V&V mitigations applied.

Explanation of Accomplishment Credits: DARP spacecraft image slide 1: “An artist conception of the autonomous DART spacecraft as it approaches the MUBLCOM satellite. … Credit: NASAexplores “ from POC: Julian Richardson (RIACS/USRA, RSE Group, Code TI, Work funded by: Reliable Software Engineering (ESAS Project 6G), Software Risk Management Task. Background: Software plays in indispensable role in all of NASA’s modern space vehicles. This means, however, that incorrect software (software “bugs” in common parlance) can contribute to system failures. There continues to be considerable work devoted to find better ways to prevent software bugs in the first place (e.g., by improving coding standards), and to detect their presence ahead of mission use (e.g., by improving tools and techniques for testing software). The “Software Risk Management” element within which this accomplishment occurs is focused on assessing the system risk that software bugs pose, taking into account the application of preventions and detections planned, or already applied, to the software. Accomplishment: We have integrated two capabilities that are crucial to analyzing software’s contribution to system failures: (1) ODC COQUALMO, a University of Southern California/NASA Ames developed tool for predicting how many software bugs are present in a software system. Importantly, this tool includes estimates of the effectiveness of practices at preventing/detecting bugs. Furthermore, to categorize bugs (different kinds of bugs have different prevalences, and have different effects) it uses an IBM-developed technique, Orthogonal Defect Classification, adapted for NASA use. (2) DDP, a JPL developed tool for representing bugs and fault trees that relate those bugs to their potential contribution to system failures. Importantly, this tool includes the capability to also represent the available practices to prevent/detect bugs, and (provided it is populated with the appropriate data), calculate the failure probabilities of the various choices among those practices. Our integration involved both determining how to integrate these tools, and also developing a prototype implementation that realizes that integration. This implementation is hosted in the Eclipse software development environment, which the Reliable Software Engineering project has adopted as the environment in which to host its developments in a unified fashion. Benefits: This accomplishment is a significant step forward in the quantification of the impact of software – and the practices followed in the development and testing of that software – on system risk. The utility of this is in providing quantitative guidance to inform decisions among design alternatives and tradeoffs where software is involved, and in planning and managing the considerable efforts that will be expended on analysis, testing and V&V of mission-critical software. Future Work: We will be performing extensive experimentation to calibrate the efficacy of a wide gamut of practices available for preventing/detecting software bugs, including in the scope of the new and improved practices that other elements of this project are developing. We will be extending our capability to continually track and manage risk during the course of software development projects.