T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.

Slides:



Advertisements
Similar presentations
RISK ANALYSIS.  Almost all of the things that we do involve risk of some kind, but it can sometimes be challenging to identify risk, let alone to prepare.
Advertisements

Project Management and Software Quality See accompanying Word file “Software PM tools 3”
Action 1: Mission/task analysis Action 2: List Hazards Action 3: List Causes STEP 1 IDENTIFY THE HAZARD STEP 2 ASSESS THE RISK Action 1: Assess hazard.
Conference March 12 th 2009 Stourport Manor Effective Practice in CPD Leadership.
T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.
Project Management Gaafar 2007 / 1 This Presentation is uses information from PMBOK Guide 2000 Project Management Risk Management* Dr. Lotfi Gaafar.
T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 2 Dr. Thomas E. Potok
ICS Management Poor management is the downfall of many software projects Software project management is different from other engineering management.
General information CSE 230 : Introduction to Software Engineering
1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance.
12 C H A P T E R Systems Investigation and Analysis and Analysis.
Computer Engineering 203 R Smith Risk Management 7/ Risk Management The future can never be predicted with 100% accuracy. Failure to plan for risks.
Fundamentals of Information Systems, Second Edition
Questions: Choice the correct answer: 1-Capability Maturity Model for Software (SW-CMM) is used to: a- increase software process capability. b- increase.
CSC 395 – Software Engineering
RISK MANAGEMENT IN SOFTWARE ENGINEERING CSC 532 Advanced Software Engineering Term Paper Presentation Presented by : Vijaya S Karri.
T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 1 Dr. Thomas E. Potok
Information System Economics Software Project Cost Estimation.
T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.
Risk Analysis for Engineering Design J. M. McCarthy Fall 2003 Definitions Hazard Analysis Hazard Analysis Report Example for Mini Baja Nationally Recognized.
CSC 386 – Computer Security Scott Heggen. Agenda Security Management.
Why is software engineering worth studying?  Demand for software is growing dramatically  Software costs are growing per system  Many projects have.
After Lesson 6 next is Lesson 13 to fit topic on Software Development SOFTWARE PROJECT MANAGEMENT.
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.
T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.
CS /39 Illinois Institute of Technology CS487 Software Engineering David A. Lash.
1 Software Cost Estimation. Outline  Introduction  Inputs and Outputs  Methods of Estimation  COCOMO  Conclusion 2.
1 Chapter 5 Project management. 2 Project management : Is Organizing, planning and scheduling software projects.
Software Engineering Risk Management. Understanding Risks Risks involve :  Uncertainty – there are no 100% probable risks  Loss – if the risk becomes.
1 Chapter 1 Introduction to Systems Analysis and Design.
Project Management Learning Program 19 – 30 April 2010, Mekong Institute, Khon Kaen, Thailand Assumptions and Risk.
Introduction to Software Engineering ECSE-321 Unit 4 – Project Management 10/19/2015Introduction to Software Engineering – ECSE321Unit 4 – Project Management/1.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix B Rapid Application.
T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 3 Dr. Thomas E. Potok
Project Estimation Model By Deepika Chaudhary. Factors for estimation Initial estimates may have to be made on the basis of a high level user requirements.
Formal Methods in Software Engineering
Foundations of Geospatial System Development II Todd S. Bacastow Professor of Practice for Geospatial Intelligence John A. Dutton e-Education Institute.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Project Estimation techniques Estimation of various project parameters is a basic project planning activity. The important project parameters that are.
SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli.
Software Project Estimation IMRAN ASHRAF
CSCI 6231 Software Engineering Cost Estimation Supplemental Instructor: Morris Lancaster.
Project & Risk Management
2.2.3 Managing risk in a humanitarian response Learning objectives: At the end of this session, participants will be able to: Define risk List potential.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 27 Software Engineering as Engineering.
ANALISA & PERANCANGAN SISTEM Disusun Oleh : Dr. Lily Wulandari Program Pasca Sarjana Magister Sistem Informasi Universitas Gunadarma.
CSC 480 Software Engineering Project Planning. Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel.
Chapter 3 Project Management Parts of this presentation is extracted from Ian Sommerville’s slides located at
بشرا رجائی برآورد هزینه نرم افزار.
Chapter 11: Project Risk Management Information Technology Project Management, Fifth Edition.
BSA 375 Week 2 DQ 1 Describe how joint application design (JAD) might be considered a better information-gathering technique than the traditional method.
Copyright All Rights Reserved by
Why is software engineering worth studying?
Risk management Be aware. Take care.
Why Do We Measure? assess the status of an ongoing project
Unit 4 Project Design, implementation and evaluation
Air Carrier Continuing Analysis and Surveillance System (CASS)
Organization of SRS Functional Requirements: They describe what has to do and what the software should not do. They specify which outputs should be produced.
Team members: Project Manager: Facilitator: Customer Liason:
MBI 630: Systems Analysis and Design
COCOMO Model Basic.
Organization of SRS Functional Requirements: They describe what has to do and what the software should not do. They specify which outputs should be produced.
Testing web applications
Why Do We Measure? assess the status of an ongoing project
Cybersecurity Threat Assessment
Managing Project Risks and Opportunities
Software Risk Management
Risk Management Part I Dr. Zahi Yaseen Contact Us
Risk Scoring: Likelihood Less than 10%
Presentation transcript:

T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL

2 Software Engineering CS 594T. E. Potok - University of Tennessee Exam Review  CMM  Requirements Engineering  Project cost estimation  Cost Models (COCOMO)  Process Models (PERT)  Project Planning  Software Development Life Cycles  Risk Management

3 Software Engineering CS 594T. E. Potok - University of Tennessee CMM  Five levels of maturity for an organization – 1) Initial; – 2) Repeatable; – 3) Defined; – 4) Managed; – 5) Optimizing.

4 Software Engineering CS 594T. E. Potok - University of Tennessee How to gather and record requirements  Traditional approach is the JAD (Joint Application Development) session  Domain experts are taught rudimentary data modeling and data flow diagramming techniques, then lead by an expert into developing a design  A beginning design can be developed in a few days

5 Software Engineering CS 594T. E. Potok - University of Tennessee OO approach  Another methods is the use of scenarios, or use cases to gather requirements  The customer deals in his or her domain describing what the computer system should do.  The programmer needs to understand the basics of the domain, and work through inconsistencies or problems in the scenarios.

6 Software Engineering CS 594T. E. Potok - University of Tennessee Productivity  Team Productivity = Project Output/Project Effort  Programmer productivity = Programmer Output/Programmer Effort  Productivity typically measured in LOC/Person-month

7 Software Engineering CS 594T. E. Potok - University of Tennessee Basic COCOMO  Organic - small to medium size, familiar projects – Person-months=2.4(KLOC) 1.05 – Development-time = 2.5(PM).38  Semidetached - intermediate – Person-months=3.0(KLOC) 1.12 – Development-time = 2.5(PM).35  Embedded - ambitious, tightly constrained – Person-months=3.6(KLOC) 1.20 – Development-time = 2.5(PM).32

8 Software Engineering CS 594T. E. Potok - University of Tennessee PERT  Project Evaluation and Review Technique – Developed for the Navy Polaris Missile Program – Directed Acyclic Graphs of project activities – Used for estimation and control of a project

9 Software Engineering CS 594T. E. Potok - University of Tennessee Two components of risk  Potential loss or impact – What is the impact of a potential risk – If it happens, what is the result Catastrophic - substantial loss of life, money, or property Major - Significant injury, loss of money, or property Minor - Mild injury, loss of money, or property Trivial - Minimal injury, loss of money, or property

10 Software Engineering CS 594T. E. Potok - University of Tennessee Two components of risk  Probability of occurrence – What is the probability that the risk will occur – How likely is it that the risk will occur Quite likely - will occur Likely - Probably will occur Unlikely - Probably will not occur Rare - Very unlikely