University of Southern California Center for Systems and Software Engineering Risk Calculation Case Studies CS 510 Software Engineering Supannika Koolmanojwong.

Slides:



Advertisements
Similar presentations
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
Software Process Models
University of Southern California Center for Systems and Software Engineering A Look at Software Engineering Risks in a Team Project Course Sue Koolmanojwong.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Filling the Gap Between System Design & Performance Verification Rafik HENIA, Laurent RIOUX, Nicolas SORDON Thales Research & Technology.
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 Software Engineering CSE USC MBASE Essentials Planning and control Milestone content Process models Life cycle.
University of Southern California Center for Systems and Software Engineering USC CSSE Research Overview Barry Boehm Sue Koolmanojwong Jo Ann Lane Nupul.
Software Engineering. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000.
Software Evolution Managing the processes of software system change
Software Engineering.
Marakas: Decision Support Systems, 2nd Edition © 2003, Prentice-Hall Chapter Chapter 7: Expert Systems and Artificial Intelligence Decision Support.
University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC CS 510, CS 577a Fall,2005 (
University of Southern California Center for Software Engineering CSE USC Distributed Assessment of Risk Tool DART Jesal Bhuta
 Software Software  Program vs Software Products Program vs Software Products  Software Characteristics Software Characteristics  Software Crisis.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Don Cole Risk Assessment and Mitigation Project Management for ARA Engineers and Scientists.
Upstream Prerequisites
Chapter 2 What is software quality ?. Outline What is software? Software errors, faults and failures Classification of the causes of software errors Software.
CLEANROOM SOFTWARE ENGINEERING.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Software System Engineering: A tutorial
CS3100 Software Project Management Week 26 - Quality Dr Tracy Hall.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
1 Software quality - Definition IEEE 1. The degree to which a system, component, or process meets specified requirements. 2. The degree to which a system,
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Software Engineering Management Lecture 1 The Software Process.
1 Project Risk Management Project Risk Management Dr. Said Abu Jalala.
Software Project Management With Usage of Metrics Candaş BOZKURT - Tekin MENTEŞ Delta Aerospace May 21, 2004.
© The McGraw-Hill Companies, Software Project Management 4th Edition Risk management Chapter 7.
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Introduction to Software Engineering ECSE-321 Unit 4 – Project Management 10/19/2015Introduction to Software Engineering – ECSE321Unit 4 – Project Management/1.
University of Southern California Center for Software Engineering C S E USC Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6 Barry.
University of Southern California Center for Systems and Software Engineering Barry Boehm, USC CS 510 Software Planning Guidelines.
EG280 Computer Science for Engineers Fundamental Concepts Chapter 1.
CS 577b Software Engineering II -- Introduction
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Pre-Project Components
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CSCI 521 Final Exam Review. Why Establish a Standard Process? It is nearly impossible to have a high quality product without a high quality process. Standard.
Motorola Internal Use OnlyGlobal Software – Performance Excellence Engineering Induction Training Program (E-ITP) Project Management Part 4 SG Performance.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Project & Risk Management For next class -- Pressman: 3, , 5.8, , 6.6 Introductions Software Development Processes Software Maturity Models.
University of Southern California Center for Systems and Software Engineering Software Metrics and Measurements Supannika Koolmanojwong CS577 1.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Software Project Management Lecture 5 Software Project Risk Management.
Stand Up Comedy Project/Product Management
Software Development Life Cycle (SDLC)
Objectives Understand Corrective, Perfective and Preventive maintenance Discuss the general concepts of software configuration management.
Risk Analysis 19 th September, Risk vs. Problem Risk  An “uncertain event that “may” happen with some probability Problem  The above event.
1 Software Risk Management : Overview and Recent Developments LiGuo Huang Computer Science and Engineering Southern Methodist University.
University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC CS 510, CS 577a Fall 2015 Software Risk Management : Overview.
Software Engineering Lecture 8: Quality Assurance.
University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE Page 1 A Winsor Brown CS 577a Lecture Fall.
1 Chapter 11 Planning. 2 Project Planning “establishing a predetermined course of action within a forecasted environment” “establishing a predetermined.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
R i s k If you don’t attack risks, they will attack you.
11 CPIT 456 by Dr. M. Rizwan Jameel Qureshi Chapter 3 Risk Management.
Software Development Process includes: all major process activities all major process activities resources used, subject to set of constraints (such as.
CS 577b: Software Engineering II
IEEE Std 1074: Standard for Software Lifecycle
(Building Information Modelling
SDLC Model A framework that describes the activities performed at each stage of a software development project.
COCOMO Models.
Quality by Design (QbD)
Software Risk Management : Overview and Recent Developments
Presentation transcript:

University of Southern California Center for Systems and Software Engineering Risk Calculation Case Studies CS 510 Software Engineering Supannika Koolmanojwong

University of Southern California Center for Systems and Software Engineering Outline Risk Management Case Studies Risk Reduction Leverage Case Studies 2

University of Southern California Center for Systems and Software Engineering Importance of Risk Management Avoiding Disasters –80-20 rule Avoiding Rework –Rework of erroneous requirements, design, code typically consumes 40-50% of the total costs of software development –Prime opportunity to improve productivity Avoiding Overkill –Focus effort on the critical areas that make a difference Stimulating Win-Win Situations –“Best and final offer” negotiation on software contracts leads to cheapest wins 3

University of Southern California Center for Systems and Software Engineering Software project’s general risks Error prone products Costly, late fixes Out-of-control projects Out-of-control products 4 testing and verification Early requirements and design v&v Project planning and control functions Config mgnt and QA functions

University of Southern California Center for Systems and Software Engineering Requirements Risks Developing the wrong software functions Developing the wrong UI Gold Plating Continuing stream of requirements changes 5

University of Southern California Center for Systems and Software Engineering Straining Computer Science Capabilities (1989) Distributed Processing Artificial Intelligence Domains Human-machine performance Algorithm speed and accuracy Information privacy and security protection High reliability and fault tolerance 6

University of Southern California Center for Systems and Software Engineering Decision-Driver If decisions had been driven by factors other than technical and management achievability, frequently be the source of critical software-risk item. 7 Politically driven decisions Choice of equipment, subcontractor, schedule & budget, allocation of responsibilities Marketing-driven decisions Gold plating, choice of eq, schedule & budget

University of Southern California Center for Systems and Software Engineering Decision – Driver (cont) Solution-driven vs problem-driven decisions In-house components and tools, product champion Short-term vs Long-term decisions Staffing – available basis rather than the qualified ones Software reuse – often flaky and incompatible Premature review – fixed review date 8

University of Southern California Center for Systems and Software Engineering Pareto phenomena 80% of the contribution comes from 20% of the contributors –20% of the modules contribute 80% of the cost –20% of the modules contribute 80% of the errors –20% of the errors cause 80% of the down time –20% of the errors consume 80% of the cost to fix –20% of the modules consume 80% of the execution time 9

University of Southern California Center for Systems and Software Engineering Uncertainty Areas and unresolved questions Mission requirements –Vague top-level mission statements but no clear definition Life-cycle concept of option –Boundaries between maintenance and incremental development or preplanned product improvement System performance drivers –Where to measure (CPU, main memory, communication) UI characteristics –IKIWISI Interfacing system characteristics –Sharing common resources? Common modules? 10

University of Southern California Center for Systems and Software Engineering Dealing with compound risks Pushing technology on more than one front –Too many new technology at the same time Pushing technology with key staff shortages Meeting vague user requirements on an ambitious schedule Untried hardware with an ambitious schedule Unstable interfaces with an untried subcontractor 11

University of Southern California Center for Systems and Software Engineering Make or Buy Decision Analysis 12 Geographic DBMS $1,200K $1,800K $700K $1,500K $2,500K $1,000K $2,000K BUILD REUSE BUY EASY HARD SMALL MOD LARGE MOD EASY HARD SMALL MOD LARGE MOD = (0.4*1200K) + (0.6*1800K) = $1,560K =$1,450K =$1,400K

University of Southern California Center for Systems and Software Engineering Do IV&V or not? 13 P(Loss) = 0.36, Find CE NO IV&V DO IV&V 0.04 Don’t Find CE 0.6 NO CE 0.3 Find CE 0.1 Don’t Find CE 0.6 NO CE Size(Loss) = $0.5 M $20.5M $0.5M Size(Loss) = $0 M $20M $0M $0.18M $0.82 M $0.30 M $1.3M $0 $20M $0 $2M

University of Southern California Center for Systems and Software Engineering 10/14/05©USC-CSE14 Risk Reduction Leverage (RRL) RRL - RE BEFORE - RE AFTER RISK REDUCTION COST · Spacecraft Example LOSS (UO) PROB (UO) RE B B LONG DURATION TEST $20M 0.2 $4M FAILURE MODE TESTS $20M 0.2 $4M PROB (UO) RE A A 0.05 $1M 0.07 $1.4M COST$2M$0.26M RRL = = 10