University Of Houston Clear Lake Syllabus
Continuous Risk Management (SENG 5232)
Location: UHCL
Instructor: Dr. James C. Helm
1.
Semester Credit Hours: Three (3)
Fall Semester 2002 Revision Date: August 26, 2002
Course Text:
Hall, Elaine M., Managing Risk: Methods for Software Systems
Development, Addison-Wesley, 2001. ISBN 0-201-25592-8
Reference: Dorofee, A. J.; Walker, J.A.; Alberts, C.J.; Higuera, R. P.; Murphy, R. L.;
Williams, R. C., Continuous Risk Management Guidebook, Pittsburgh, Pa.: Software
Engineering Institute, Carnegie Mellon University, 1996.
2.
Course Description:
Continuous Risk Management is a software engineering practice with processes, methods, and
tools for managing risks in a project. It provides a disciplined environment for proactive
decision making to assess continuously what could go wrong (risks), determine which risks
are important to deal with, and implement strategies to deal with those risks. The purpose of
this course is to explain what Continuous Risk Management is; to help you understand the
principles, functions, methods, and tools; to show what it could look like when implemented
within a project; and to show you how a project could implement its own adaptation.
3.
Course Objectives:
This Course will enable students to:

Understand the concepts and principles of Continuous Risk Management and how
to apply them.

Develop basic risk management skills for each component of Continuous Risk
Management.

Be able to use key methods and tools.

Be able to tailor Continuous Risk Management to a project.
4.
Course Requirements:
A. End of Module Assignments: The student shall complete the eleven- (11) end of module
assignment. The end of module assignments for this course is given in Section 7. End of
Module Assignments.
B. Written Report: The written report topic, format, length, and style is given is Section 8.
Project Guidelines.
5.
Evaluation & Grading:




The student will be grade on the following:
Mid-term Examination .................................................................... 25%
Final Examination ........................................................................... 25%
Average grade for End of Module assignments .............................. 25%
Risk Management Plan Student Hypothetical Research Project ..... 25%
Page 1 of 5
6.
Courses Outline:
1
2
3
4
5
6
7
8
9
10
11
12
Introduction Read Chapter 1
Read Chapter 2-3
Risk Management Data Flow
Module Assignment -1Identify Read Chapter 4
Risk Information Sheet
Exercise : Writing Risk Statements
Module Assignment -2Risk Information Sheet After Identification
List of all Case Study risks
Taxonomy-Based Risk Identification
Goal-Driven Risk Management
Module Assignment -3Analyze Read Chapter 5
Analysis - Risk Information Sheet
Tri-level Attribute Evaluation Exercise
Exercise: Multivoting Form
Module Assignment -4Risk Information Sheet after Analyze
Software Risk Checklist - Taxonomy
mid-term Examination
Module Assignment -5Plan Read Chapter 6
Planning Decision Flowchart
Task Plan - Case Study
Module Assignment -6Planning Worksheet - Case Study
Planning Worksheet After Planning
Module Assignment -7Track Read Chapter 7
Spreadsheet Risk Tracking - Case Study
Module Assignment -8Control Read Chapter 8
Mitigation Status Reports
Risk Information Sheet After Tracking & Control
Communicate & Document
Module Assignment -9How to Implement CRM Read Chapter 9-15
Methods & Tools
Risk Management Plan - Case Study
Risk Implementation Plan - Case Study
Module Assignment -10Summary Read Chapter 16-23
Module Assignment -11Final Examination
Read Module Handouts 1
Read Module Handouts 2
2a
Read Module Handouts 3
3a
3b
3c
Read Module Handouts 4
Slide 4 - 11 - 13
4b-1
4c
Example
Read Module Handouts 5
5a
5b
5c
5d
Read Module Handouts 6
6a
Read Module Handouts 7
7a
7b
Read Module Handouts 8
Read Module Handouts 9
9a
9b
9c
Read Module Handouts 10
Page 2 of 5
7.
End of Module Assignments:
1. Module Assignment 1: You are the technical lead for a commercially available
requirements management tool. Your supervisor has come to you for a make-or-buy
decision: In the next tool release, should you develop an object-oriented database inhouse, or use an existing third-party object-oriented database package? Use a decision
tree to diagram decision, chance event, and outcome nodes. Discuss the parameters of this
decision from three perspectives: risk averse, risk seeking, and risk neutral.
2. Module Assignment 2: What is a risk assessment? Cite three reasons to perform a risk
assessment early in the project. Imagine that you were brought in to replace a retiring
project manager of a project in the design phase. Would you delegate the task of
performing a risk assessment? Discuss the ways a baseline of assessed risks would be
valuable to you.
3. Module Assignment 3: Develop a risk checklist for the requirements, design, code, or
test phase of software development. Which phase do you think has the greatest risk?
Explain you answer.
4. Module Assignment 4: List five ways that a risk database can assist the risk analysis
process. How would you ensure that the risk database is maintained?
5. Module Assignment 5: Many risks are interrelated. Analyze the following compound
risk: Unstable requirements with tight budget will likely cancel the project. Discuss the
dependencies that exist between the two risks.
6. Module Assignment 6: A significant integration risk has been identified. The cause is
determined to be a lack of thorough software testing due to insufficient time allocated to
the integration and test phase. You have been assigned to investigate this risk and make
recommendations to reduce the risk. Project management wants to maximize software
quality and minimize total cost. How would you trade off these conflicting objectives?
What are your recommendations to project management regarding risk?
7. Module Assignment 7: Discuss the following human traits that are useful in coping
with uncertainty: attitude, belief, confidence, courage, faith, and imagination. Which trait
do you think is the most important? Explain your answer.
8. Module Assignment 8: Discuss the consequences of reporting risk metrics that are not
timely, validated, economical, and understandable.
9. Module Assignment 9: Your requirements specification contains 100 requirements.
The design phase began even though 20 percent of the requirements had TBDs (to be
determined shall statements). The best-case outcome is that all your assumptions will be
correct. Your training in risk management leads you to believe that about half of the
TBDs are at risk. Calculate the cost of rework based on the assumption that half of the
TBDs are at risk. What is the most likely outcome?
Page 3 of 5
10. Module Assignment 10: List five responsibilities associated with the role of system
engineer. For each responsibility, provide a risk that might occur. Identify the associated
interface for communication regarding each risk.
11. Module Assignment 11: List ten general categories of software risk that you would
expect to find early in the project. Would you expect that most projects that perform a risk
assessment early in their life cycle have the same logical grouping of risk? Explain you
answer.
Section 8.
Project Guidelines
The written report is a risk management plan that the student develops from a hypothetical
software/hardware project. The style and format of the term paper should be the same as the Risk
Management Plan given in Unit 11 Module 9b. It is highly desirable that Microsoft word be used to
match the style and format of the Risk Management Plan Case Study.
Project Manager Information Assumptions For Your Project
These are the ideas and information concerning the project manager and the lead software engineer
interested in working on the project you have decided to build. Assume that you have already
developed the project description, so the following description is the situation the project is in at the
time you start. At his time the concept (vision) document has been completed.
This is the first system he/she has managed of this magnitude and complexity. However he/she
believes it is going to be a very positive experience for himself/herself and the rest of the personnel
on the project. All his/her other projects were control systems and they were all very successful. The
people working on the project are very good and they’ve done these types of projects before, but one
of the project manager’s goals is to streamline the development process. It’s a competitive world for
funding your project needs to be cost-efficient and may need tools to help the development cycle.
In order to reduce administrative costs, the project manager decided to reduce project overhead by
having only a secretary, a financial manager and an assistant project manger. The project manager
and Assistant Project manager will make all technical decisions.
Rather than using the very costly center configuration control system, the project manager decided to
allow the hardware manager and the software manager to use whatever configuration management
process they are comfortable with. Each will prepare a configuration management plan and submit it
to the project manager to be incorporated into the project plan.
The software engineers working for the software manager are just a fantastic bunch of people some of
them just out of college. They are always willing to put in extra time to meet schedules and find
really efficient workarounds for the hardware issues. The project manager thinks that software can fix
just about any problem the hardware group comes up with.
The company’s system development is based on good, solid engineering principles that apply to any
project. The waterfall life cycle has always done very well for the project manager and that is what he
will use on this project. Therefore, he/she foresees no problems whatsoever.
Assume that your project will be completed on a reduced schedule, after the project manager spoke to
his team managers. He/she looked at the original schedule put together by the predecessor and that
person was far too pessimistic. With the current schedule, the project manager got the schedule down
Page 4 of 5
to a lean operation with delivery four months sooner. This will get the team to the integration
milestone with the necessary hardware.
Due to the short time to design, build, test and install the software, the project manager decided that
the hardware test program would be limited to subassembly tests of the instruments and a functional
test performed on the entire project prior to delivery.
The project manager also decided to use commercial grade foreign parts in the project and
instruments because they are more readily available, and are less expensive than tested qualified parts.
Besides, many of the tested qualified parts have procurement lead times of 18 months or more.
The project is currently in the requirements definition stage of the life cycle. Things are going
marvelously. The project manager knows that the project is a little late in defining some of the
interface requirements, and that’s causing the project to slip a bit, but the team can work around the
TBD requirements. They are waiting for some of the interface requirements to become solid before
they design their software. Therefore they feel that they have plenty of time. And besides, the project
manager believes he/she will be able to upload changes to the software system during operations
anytime a module needs to be fixed and if requirements are missing anything, it will not be a disaster.
Since the project is in the requirements stage of the live cycle, the project manager thinks one of the
most exciting opportunities of new project is that this is the first project at the company to use object
oriented design and the C++ programming language. Every single one of the software people has the
chance to learn something new on this project. This will put the software engineers on the forefront
of the technology curve and really bring the software team into the future. The software manager has
also selected one of the newest C++ compilers with all the latest features to help improve the software
development efficiency.
The experiments/events/activities the project is going to be able to do with this new system will be
fantastic.
The users/stakeholders are quite enthusiastic about coming up with more
experiments/projects/activities that they can do with the project. The users/stakeholders actually have
more experimenters signed on than were originally expected so they will be able to make total use of
all/percent of the operations time of the system.
Page 5 of 5