Send To Printer

University Of Houston Clear Lake Syllabus

 

Continuous Risk Management (SENG 5330)

 

Location: UHCL                                           Semester Credit Hours: Three (3)

Instructor: Dr. James C. Helm          Fall Semester 2003       Revision Date: August 11, 2003

 

1.         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%

 

 

 

6.         Courses Outline:

Week

Topic Fall Schedule 2003

Reading

Assignment

Week 1

Module 1 Introduction and Buy the Textbook.

Module 1 and Textbook Chapters 1-2

Read Textbook Managing Risk by Elaine Hall Chapter 1-2-3

Week 2

Module 2 Risk Management Paradigm

Module 2 and Textbook Chapter 3

Module 1 Assignment from Textbook.  Due Week 4

Week 3

Module 3 Identify.  The Risk Information Sheet.  The Case Study.

Module 3 and Textbook Chapter 4.  Read the Case Study.

Module 2 Assignment from Textbook.  Due Week 5

Week 4

Module 4 Risk Information sheet after Identify.  Methods and Tools.

Module 4

Module 3 Assignment from Textbook.  Due Week 6

Week 5

Module 5 Analyze

Begin Project

Module 5 and Textbook Chapter 5

Module 4 Assignment from Textbook.  Due Week 7

List of all Case Risk Study.  Taxonomy-Based Risk Identification.  Goal-Driven Risk Management

Week 6

Module 6 Risk Information Sheet after Analyze.  Multivoting Example.

Module 6

Mid-Term Examination

Module 5 Assignment from Textbook.  Due Week 8

Week 7

Module 7 Plan.  Plan Elements, Research, Accept Watch, Mitigate.

Module 7 and Textbook Chapter 6

Module 6 Assignment from Textbook.  Due Week 9

Software Risk Checklist - Taxonomy Example

Week 8

Module 8 Risk Information Sheet After Plan.  Task Plan Example.  Mitigation Planning Worksheet.  Methods and Tools

Module 8

Module 7 Assignment from Textbook.  Due Week 10

Week 9

Module 9 Track.  Case study Spreadsheet Risk Tracking.  Methods and Tools

Module 9 and Textbook Chapter 7

Module 8 Assignment from Textbook.  Due Week 11 

Week 10

Module 10 Control.  Completed Risk Information sheet after Track and Control.  Methods and Tools.

Module 10 and Textbook Chapter 8

Module 9 Assignment from Textbook.  Due Week 12

Week 11

Module 11 Communicate & Document.  What is communication?  Relationship to other paradigm functions.  Enablers to communication.  Barriers to communication.  Documentation of Risks.  Methods and Tools.

Module 11 and Textbook Chapter 9

You should read the entire book but you will not be tested on the Textbook past chapter 9.

Module 10 Assignment from Textbook

Due Week 13

Week 12

Module 12 How to Implement CRM

Module 12

All (10) module assignments are due beginning of the week.

Week 13

Module 13 Course Summary

Module 13

Turn in Project.

Week 14

Final Examination

 

 

 

 

 

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 in-house, 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?

 

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.

 

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 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.