Summer 8 Session June 5-- July 29, 2024
15356 SENG 5330 Continuous Risk Management
Location: UHCL 2700 Bay Area
Instructor: Dr. James C. Helm
Office Delta Building Room 123 Email for appointment email: helm@uhcl.edu
Blackboard logon http://blackboard.uhcl.edu
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
six- (6) end of module assignment in the summer session. 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 .......................................................................
35%
·
Final Examination ..............................................................................
35%
·
Average grade for the 4 Module assignments ............ ....................... 15%
·
Risk Management Plan Student Hypothetical Research Project ............15%
6. Courses Outline:
|
Week |
Topic |
|
Assignment |
|
Week 1 June 4 - June 10 |
Blackboard Module 1 Introduction and Buy the Textbook. |
Blackboard Module 1 and Textbook Chapters 1-2 |
Read Textbook Managing Risk by Elaine Hall Chapter |
|
Week 2 June 11-June 17 |
Module 2 Risk Management Paradigm Module 3 Identify. The Risk Information Sheet. The Case Study.
|
Module 2 and Textbook Chapter 3 Module 3 and Textbook Chapter 4. Read the Case Study. |
Module 1 Assignment from Blackboard and Syllabus Due week 3 June 18-24 Module 2 Assignment from Blackboard and Syllabus Due week 5 July 2-8 |
|
Week 3 June 18-June 24 |
Module 4 Risk Information sheet after Identify. Methods and Tools. Module 5 Analyze |
Module 4 Module 5 Textbook Chapter 5 |
Module 3 Assignment from Blackboard and Syllabus Due week 6 July 9-15 Module 4 Assignment from Blackboard and Syllabus Due week 7 July 16-22 List of all Case Study risks Taxonomy-Based Risk Identification Goal-Driven Risk Management Module 1 Due |
|
Week 4 June 25-July 1 |
Module 6 Risk Information Sheet after Analyze. Multivoting Example. Mid-Term Examination Available to Start June 25, 2023 12:00pm through July 1, 2023 pm |
Module 6 Mid-Term Examination
|
|
|
Week 5
|
Module 7 Plan. Plan Elements, Research, Accept Watch, Mitigate. Module 8 Risk Information Sheet After Plan. Task Plan Example. Mitigation Planning Worksheet. Methods and Tools |
Textbook Chapter 6 Software Risk Checklist - Taxonomy Example |
Module 5 Assignment from Blackboard and Syllabus Module 2 Due
|
|
Week 6 July 9-July-15 |
Module 9 Track. Case study Spreadsheet Risk Tracking. Methods and Tools Module 10 Control. Completed Risk Information sheet after Track and Control. Methods and Tools. |
Module 9 Textbook Chapter 7 Module 10 Textbook Chapter 8 |
Module 3 Due
|
|
Week 7 July 16-July-22 |
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 12 How to Implement CRM
|
Module 11 and 12 Textbook Chapter 9 You should read the entire book but you will not be tested on the Textbook past chapter 9. |
Module 4 Due Complete Project and |
|
Week 8 July 23-July-29 |
Module 13 Course Summary Project Due Week 8 Final Examination available July 23 12pm - July 29 11pm |
Module 13 |
Module 5 Due All (5) module assignments are due today. Project Due Week 8 |
7. Five End of Module Assignments.
1.
Module Assignment 1:
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.
2. Module Assignment 2: 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. The assignment is due in Week 5: July 4-10, 2021. Please save and upload the file with your name: e.g. your-name-Assignment-2
3.
Module Assignment 3:
List
five ways that a risk database can assist the risk analysis process. How would you ensure that the risk database
is maintained?
4. Module Assignment 4: 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. The assignment is due in Week 7: July 18-2, 2021. Please save and upload the file with your name: e.g. your-name-Assignment_4
5. Module Assignment 5 xxxxxxx your-name-Assignment_5
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. Risk
Management plan for Project ZEUS.
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.
Section 9. Honesty Code
The
Honesty Code of UHCL states "I will be honest in all my academic activities
and will not tolerate dishonesty."
Section 10. Special academic accommodations (as specified by the
Americans with Disabilities Act)
If you believe that, you have a disability requiring an academic adjustment/auxiliary aid, please contact Disability Services by phone at 281-283-2648, or email disability@uhcl.edu, or go to the office in the Student Services Building (SSCB), Room 1.302
The University of Houston System complies with
Section 504 of the Rehabilitation Act of 1973 and the Americans with
Disabilities Act of 1990, pertaining to the provision of reasonable academic
adjustments/auxiliary aids for students with a disability. In accordance
with Section 504 and ADA guidelines, each University within the System
strives to provide reasonable academic adjustments/auxiliary aids to
students who request and require them.