How does the “Iron Triangle” relate to project management?

Slides:



Advertisements
Similar presentations
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
Advertisements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 25 Risk Management
RISK MANAGEMENT IN SOFTWARE ENGINEERING RISK MANAGEMENT IN SOFTWARE ENGINEERING Prepared by Prepared by Sneha Mudumba Sneha Mudumba.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 25 Risk Management Software Engineering: A Practitioner’s Approach, 6/e Chapter 25 Risk.
Chapter 16 Software Quality Assurance
Chapter 16 Software Quality Assurance
Developed by Reneta Barneva, SUNY Fredonia Quality Concepts (Chapter 14)
Software Quality SEII-Lecture 15
Chapter 25 Risk Management
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
1 Chapter 6 Risk Management. 2 Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Software Engineering Software Process and Project Metrics.
Software Engineering Risk Management. Understanding Risks Risks involve :  Uncertainty – there are no 100% probable risks  Loss – if the risk becomes.
Risk Analysis & Management
1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
ﴀ These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
Chapter : 14 Quality Concepts
1 Lecture 11: Chapter 14 Quality Concepts Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright.
1Coming up: Project Risks Chapter 28 – Modified by Fleck Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger.
Risk Analysis 1. Project Risks 2 What can go wrong? What is the likelihood? What will the damage be? What can we do about it? Check : List of potential.
Software Engineering B.Tech IT/II Sem-II Term: Unit-7 PPT SLIDES Text Books:1.Software Engineering, A practitioner’s approach Roger s. Pressman.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Project & Risk Management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
1 Lecture 12: Chapter 16 Software Quality Assurance Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman.1.
Chapter 11 Project Management.
Chapter 33 Estimation for Software Projects
Chapter 25 Risk Management
Software Engineering (CSI 321)
Chapter 25 Risk Management
Requirements Engineering Lecture 13
Software Risk Management
Chapter 14 Quality Concepts
Chapter 19 Quality Concepts
Chapter 18 Maintaining Information Systems
Software Engineering B.Tech Ii csE Sem-II
Slide Set to accompany Web Engineering: A Practitioner’s Approach
Chapter 25 Risk Management
Risk Analysis.
Chapter 2 Software Engineering
Chapter 35 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright.
Chapter 18 MobileApp Design
Chapter 21 Software Quality Assurance
Chapter 25 Risk Management
Software Engineering (CSI 321)
Chapter 21 Software Quality Assurance
Chapter 9 Requirements Modeling: Scenario-Based Methods
Software Quality Engineering CS- 449
Chapter 2 Software Engineering
Assessing Risk Impact Factors affecting the consequences Nature Scope
Chapter 27 Security Engineering
Chapter 13 Quality Management
Chapter 25 Process and Project Metrics
Baisc Of Software Testing
Chapter 28 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001,
Chapter 28 – Modified by Fleck
Chapter 33 Estimation for Software Projects
Chapter 14 Quality Concepts
Chapter 25 Risk Management
Chapter 32 Process and Project Metrics
Software Risk Management
Presentation transcript:

How does the “Iron Triangle” relate to project management? SCOPE COST TIME How does the “Iron Triangle” relate to project management?

Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Risk Mismanagement

Risk Management In your own words, what is it? What kinds of risk are there in software projects in general? What kinds of risk are there in our electronic voting booth software?

What’s the difference between proactive and reactive risk management?

Assessing Risk Identification Probability Impact Exposure

Seven Principles Maintain a global perspective—view software risks within the context of system and the business problem Take a forward-looking view—think about the risks that may arise in the future; establish contingency plans Encourage open communication—if someone states a potential risk, don’t discount it. Integrate—a consideration of risk must be integrated into the software process Emphasize a continuous process—the team must be vigilant throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved. Develop a shared product vision—if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur. Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Building a Risk Table Risk Probability Impact RMMM Risk Mitigation Monitoring & Management These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Risk Exposure (Impact) The overall risk exposure, RE, is determined using the following relationship [Hal98]: RE = P x C where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

RMMM

Quality Risk Management Project Management

QUALITY ?? http://www.merriam-webster.com/dictionary/quality

Quality Produced and delivered on time Useful product Produced and delivered on time Adding value to both customer and producer

Quality Dimensions David Garvin [Gar87]: Performance Quality. Does the software deliver all content, functions, and features that are specified as part of the requirements model in a way that provides value to the end-user? Feature quality. Does the software provide features that surprise and delight first-time end-users? Reliability. Does the software deliver all features and capability without failure? Is it available when it is needed? Does it deliver functionality that is error free? Conformance. Does the software conform to local and external software standards that are relevant to the application? Does it conform to de facto design and coding conventions? For example, does the user interface conform to accepted design rules for menu selection or data input? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Quality Dimensions Durability. Can the software be maintained (changed) or corrected (debugged) without the inadvertent generation of unintended side effects? Will changes cause the error rate or reliability to degrade with time? Serviceability. Can the software be maintained (changed) or corrected (debugged) in an acceptably short time period. Can support staff acquire all information they need to make changes or correct defects? Aesthetics. Most of us would agree that an aesthetic entity has a certain elegance, a unique flow, and an obvious “presence” that are hard to quantify but evident nonetheless. Perception. In some situations, you have a set of prejudices that will influence your perception of quality. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

How will quality relate to our project? Quality in process Quality of product Intuitiveness of the user interface Correctness of results

Project Homework – think about the features. How can we chunk those into maybe 6 areas?

Clear instructions Simple user interface Security User Input Save data Speed of Interface The system should know the candidates The system should know the voter count The system should verify voter counts The system should prevent multiple votes The system, should provide address/precinct information The system should allow for candidates 1 vote per office Multiple votes for multiple office holders The system should allow for Amendments or Resolution or Propositions. Groups