Problem:
Provide five examples from other fields that illustrate the problems associated with a reactive risk strategy.
Answer:
Reactive risk strategy:-
A reactive strategy monitors project for likely risks.
Resources are set aside to deal with them.
Commonly the software team does nothing about risks until something goes wrong.
Then the team files into action to correct the problem.
When this fails, crisis management takes over and project is in real trouble.
Take the Example for Safe Home:
Putting a stop sign at a dangerous corner only after a fatal accident has occurred;
Fixing a pothole only after the city has been sued by an angry motorist.
Implementing financial safeguards only after fraud has occurred.
Putting in an alarm system only after the house has been burglarized.
In essence, we react instead of planning.
Problem:
Describe the difference between “known risks” and “predictable risks.”
Answer:
Risk management is the process of identifying, managing and controlling threats or risks from the various sources in the system.
• Risk is the situation where the external or internal factors cause a threat of damage, injury, loss or any other negative occurrence in the system.
• Risk is the potential of gaining or losing resulting from actions like unpredictable, uncontrollable and irrelevant outcomes that occur based on the performance of the system.
• Risk is a potential problem – it might happen and it might not. There are several risks originate from different situations in the system.
The difference between Known Risks and Predictable Risks are explained below:
Known Risks are those that can be uncovered after careful evaluation of the project plan, business and technical environment in which the project is being developed, and other information sources.
• Known risks are somewhat predictable and proactively managed.
• In known risks, known indicates those risk can be identified, analysed and planned in the project.
• This is the easiest risk for most of the people because it is controllable.
• A known risk means that the system could understand what the challenges will come around during the project execution.
• These are risks that have been correctly identified and properly measured.
For example,
• The known risks are unrealistic delivery date
• Lack of documented requirements
• Lack of software scope
• Poor development environment.
Figure 1: Risk Management usage of Known Risks
Predictable Risks are those that are extrapolated (Known Data) from past project experience.
• These risks are executed based on the previously known data and from the experience in the project.
• Also, these are predicted risks that are already known.
• Predictable risks are easy to identify from past experience and easy to analyse it.
For example,
• Past turnover
• Staff turnover
• Poor communication with the customer
• Reduction of staff effort as ongoing maintenance requests is serviced.
Figure 2: Risk management usage of Predictable Risks
Problem:
Add three additional questions or topics to each of the risk item checklists presented at the SEPA website.
Answer:
Identify risks is to create a risk item check list.
The check list focuses on risks.
1. product size
2. Risks associated with the over all size of software to be built or modified.
3. Business impact
4. Risks associated with constraints imposed by management or market place.
5. Customer characteristics.
6. Risks associated with sophistication of the customer and the developers ability to communication with the customer in a timely manner.
7. process definition
8. Risks associated with the degree to which the software process has to defined and followed by the development organization.
9. development environment
10. Risks associated with availability and quality of the tools to be used in product development.
11. technology to be built
12. Risks associated with complexity of the system to be built and the “newness” of technology that is packaged by the system.
13. Staff size ad experience.
14. Risks associated with the over all technical & project experience of the software engineers.
Problem:
You’ve been asked to build software to support a low-cost video editing system. The system accepts digital video as input, stores the video on disk, and then allows the user to do a wide range of edits to the digitized video. The result can then be output to DVD or other media. Do a small amount of research on systems of this type and then make a list of technology risks that you would face as you begin a project of this type.
Answer:
The following activities are to be done in a low cost video editing system:
1. It should accept a digital video as input.
2. It should store the video on disk.
3. It should allow the users to do changes.
4. It should store the modified video in DVD or any other media.
Following are some of the technology risks associated in developing a low cost video editing system:
1. Need to consider various formats of the digital video. The formats keep changing rapidly.
2. Need to consider various compression algorithms. There is a frequent change in the compression algorithms.
3. Need to consider frequent changes in processing power and bus architectures.
4. Need to consider various modes of uploading or inputting the digital video. The modes of inputting the digital video changes from time to time (via internet, direct from camera, direct from mobile, from LAN, from analog tape, etc.).
5. Need to consider various media for storing the modified video (DVD, camera, mobile etc.).
Problem:
You’re the project manager for a major software company. You’ve been asked to lead a team that’s developing “next generation” word-processing software. Create a risk table for the project.
Answer:
Risk Table:- Risk impact define as:
Catastrophic - 1
Critical - 0.7
Major - 0.5
Minor - 0.2
| Risk Category | Risk | Risk Impact | Probability | Note |
| Project Risk | ||||
| Project Complexity | Catastrophic | 10 | ||
| Cost | Major | 5 | ||
| Schedule | Minor | 2 | ||
| Personnel | Minor | 1 | ||
| Resource | Minor | 1 | ||
| Requirements | Minor | 1 | ||
| Technical Risk | ||||
| Technical | Catastrophic | 8 | ||
|
| critical | 6 | ||
| design | Major | 5 | ||
| maintenance | Minor | 1 | ||
| interoperability | Major | 10 |
Risk probability can’ be defined at 1 to 10
In the above risk table 10 is the highest.
Problem:
Describe the difference between risk components and risk drivers.
Answer:
The project manager identity the risk components by indicate the four areas of impact. That will be affected by risk. That is, risk can impact through performance, cost, support, or schedule.
Where as risk drivers are the risks that will have a focused impact on the risk components each risk driver on the risk component is divided into one of four impact categories. Those are
1. Negligible,
2. Marginal,
3. Critical
4. Catastrophic.
For example,
1. Some risks will have an affect on schedule
2. Other risks might drive the performance component.
Problem:
Develop a risk mitigation strategy and specific risk mitigation activities for three of the risks noted in Figure 35.2.
FIGURE 35.2 Sample risk table prior to sorting
Answer:
Risk mitigation strategy and risk mitigation activities.
(1) Staff inexperienced:
Strategy:
1. May take longer to define the project and build work plan.
2. May make more mistakes in judgment, causing rework and project delays.
3. More difficulty organizing and managing a complex project.
4. May not be familiar with sound project management practices.
5. May not know when to all for help.
Activities:
1. Provide up-front project management training.
2. Designate a more senior person to coach and mentor the project manager.
3. Break the project into smaller pieces that are easier to manage.
4. Put a strong quality-assurance process in place to ensure the project is on the right tract.
5. Make sure the major deliverable are formally approved.
6. Utilize strong team leaders and team members to bring additional experience to bear.
(2) Technology will not meet expectations:
Strategy:
1. Learning curve may result in lower initial productivity.
2. May be integration problems between old and new technology.
3. Resistance to technology changes may cause the project to be delayed.
4. May be difficulty testing the new technology.
5. Technology may not be installed or configured correctly, which will lead to project delays.
6. New tools can lead to longer delivery times.
7. New technology may require substantial conversion efforts.
8. System performance may be poor while expertise is gained in optimizing and configuring the technology.
Activities:-
1. Provide as much training on the new technology as practical, as early as possible.
2. Train every one that needs to install, use, or support the new technology.
3. Make arrangements to rely on vendor technical specialists, when needed.
4. Use outside consultants who are familiar with technology.
5. Make sure there is an adequate test environment where the technology can be utilized without affecting production.
6. Ensure that solid analysis is completed regarding the new technology functions, features and capabilities.
7. Create procedures and standards for how the new technology should be utilized.
8. Create a pilot test or prototype to utilize the new technology in a small way at first.
3) Larger number of users than planned:
Strategy:
1. Implication of a high number of effort hours is that there are many people involved and more complexity.
2. Harder to communicate effectively with the team.
3. Bottlenecks can occur when decisions are needed quickly.
4. More chance to people problems.
5. Increase chance of turnover.
6. More people to train.
Activities:-
1. Use a project management tool to control resource utilization.
2. Have team members utilize weekly status reports to report on progress against their assigned work plan activities.
3. Utilize team leaders to manage sub teams.
4. Organize team-building activities to build collision.
5. Schedule status meeting to keep people informed of project status.
6. Utilize structured internal procedures for scope, issue, quality and risk management.
7. Break the project into smaller sub projects.
8. Reduce available project work time per person, per day to recognize additional people and man related activities.
Problem:
Develop a risk monitoring strategy and specific risk monitoring activities for three of the risks noted in Figure 35.2. Be sure to identify the factors that you’ll be monitoring to determine whether the risk is becoming more or less likely.
FIGURE 35.2 Sample risk table prior to sorting
Answer:
As the project proceeds, risk monitoring activities commerce the project manager monitors the factors that may provide an indication of whether the risk is becomes more or less.
If size estimate is considered then it may be low significant and the following factors can be monitored
1. Its depend on the number of team member and working on the particular project
2. Interpersonal relationships among team members.
Incase customer will change requirements. The following factors can me monitored.
If change requirements are consider than it may be
(i) Starting of the project
(ii) Middle pf the project
(iii) Ending of the project
If change requirements occur at starting of the project than, the risk is becoming less.
If change requirements occur at middle of the project than, the risk is becoming tough.
If change requirements occur at end of the project than, the risk is becoming more
Risk management and contingency planning assumes that mitigation efforts have failed and that risk has become a reality.
Mitigation:
(1) Develop a training schedule for all software staff that is "just-in-time." That is, training will be provided just before the tool is required for use.
(2) Have one or two experts on staff for each tool. These people will be available to mentor others in the use of the tool and answer questions.
Monitoring:
(1) Log number of hour's tools is being used.
(2) Debrief staff to determine how tools are perceived; whether frustration is setting in;
(3) Examine work products created using tools for quality;
(4) Determine time required to create work products using tools vs. manual approach look for anomalies.
Problem:
Develop a risk management strategy and specific risk management activities for three of the risks noted in Figure 35.2.
FIGURE 35.2 Sample risk table prior to sorting
Answer:
Risk management strategy and specific risk management activities:-
The staff turn over is a high risk
Strategy:
• Impact is serious on cost and schedule.
• Meet with current staff to determine causes for turn over (eg. Conditions, pay, completion.
Activities:
• Back up is available.
• Information has been documented.
• Knowledge is dispersed across the team.
Customer will change requirements
Strategy:
Derive traceability information to assess requirement change impact, maximize information hiding in the design.
Problem:
Attempt to refine three of the risks noted in Figure 35.2, and then create risk information sheets for each.
FIGURE 35.2 Sample risk table prior to sorting
Answer:
The format of risk information sheet:-
RISK INFORMATIO SHEET
RISK ID DATE PROB IMPACT
Description:-
Refinement/content:-
Mitigation Strategy:-
.
Contingency plan and trigger:-
Current status:
Originator: Assigned:
Problem:
Represent three of the risks noted in Figure 35.2 using a CTC format.
FIGURE 35.2 Sample risk table prior to sorting
Answer:
Represent risk in CTC (condition-transition – consequence) format.
The risk is stated in the following form:
Given that then there is concern that (possibly)
Condition:
1) Given that no perfect plan for delivery concern that (possibly) delivery dead line will be tightened.
2) Given that no proper technology then there is concern that technology will not meet expectations.
3) Given that the size estimate be significantly lower than the size of the actual system being built then there is a concern that (possibly) only 60% of the project will be completed within the time allocated for the completion of the project.
Problem:
Recompute the risk exposure discussed in Section 35.4.2 when cost/LOC is $16 and the probability is 60 percent.
Answer:
The overall risk exposure, RE, is determined using the following relationship.
Where P is the probability of occurrence for a risk,
C is the cost to the project should the risk occur.
Here risk probability = 60 percent.
Cost/LOC 
Risk exposure 
Problem:
Can you think of a situation in which a high-probability, high-impact risk would not be considered as part of your RMMM plan?
Answer:
As part of RMMM plan, high probability, high-impact risk would not be considered on
1. Requirements are fully understood.
2. The software teams have right mix of skills.
3. Project requirements are stable.
4. The project teams have experience with the technology to be implemented.
If we considering the above risk as high probability, high impact, than the project team cannot do anything to mitigate, monitor, or manage it. At this time it should not appear in the risk table.
Let the example for RMMM plan:
Risk: from table — "Lack of training on tools"
Mitigation: (1) Develop a training schedule for all software staff that is "just-in-time." That is, training will be provided just before the tool is required for use. (2) Have one or two experts on staff for each tool. These people will be available to mentor others in the use of the tool and answer questions.
Monitoring: (1) Log number of hour’s tools is being used. (2) Debrief staff to determine how tools are perceived; whether frustration is setting in; (3) examine work products created using tools for quality; (4) determine time required to create work products using tools vs. manual approach—look for anomalies.
Management: Assumes that tools are not working. Determine reasons why. If staff is untrained, then provide one-to-one mentoring/training using staff experts and vendor trainers (budget for this contingency). If training is OK but tools don’t work, then consider alternative work product generation approaches using a semi-automated approach, e.g., word processors and graphical tool and a stripped down version of required models.
Problem:
Describe five software application areas in which software safety and hazard analysis would be a major concern.
Answer:
Software safety and hazard analysis are quality assurance activities that are of particular concern for these types of applications. If hazards can be identified early in the software process, software design features can be specified that will either eliminate or control potential hazards.
Five application areas are
1. Medical equipment Application,
2. Avionics Application
3. Power plant control (especially nuclear) system.
4. Automobile control systems,
5. Radar Systems
In addition, systems that are involved in national security and systems that facilitate major economic transactions are also candidates.
Solution: Chapter 35: RISK MANAGEMENT
35.1Reactive risk management occurs ‘once the horse has left the barn.’ A few examples: putting a stop sign at a dangerous corner only after a fatal accident has occurred; fixing a pothole only after the city has been sued by an angry motorist. In essence, we react instead of planning.
35.2Known risks are those that are determining through careful evaluation of the project and technology. Predictable risks are extrapolated from past experience.
35.3 Answers will vary
35.4Technology risks:
- Rapid changes in digital format for video data
- Changing compression algorithms and format
- Rapid changes in processing power and bus architectures
- Rapid changes in video input modes (e.g., via internet, direct from camera, across LAN, from analog tape, from DAT),
All of the above represent technology risk for the project
35.5Business risks here are probably the most relevant, although your students will likely select technical and project risks. Be sure to indicate that business risks (i.e., large market share of existing WPs with significant penetration problems); industry standard WPs (e.g., MSWord) will cause reticence to buy, etc. may be significantly more important than technical or project risks.
35.6 Risk components indicate the four areas of impact that will be affected by risk. That is, risk can impact performance, cost, support, or schedule. Risk drivers are the risks that will have a focused impact on the risk components. For example, some risks will have an affect on schedule; other risks might drive the performance component.
35.7Realistically, the scheme noted is probably sufficient. See Karolak for more detailed risk model with more sophisticated weighting.
35.8 to 35.10Single example of RMMM is provided to illustrate the approach:
Risk: from table — "Lack of training on tools"
Mitigation: (1) Develop a training schedule for all software staff that is "just-in-time." That is, training will be provided just before the tool is required for use. (2) Have one or two experts on staff for each tool. These people will be available to mentor others in the use of the tool and answer questions.
Monitoring: (1) Log number of hour’s tools is being used. (2) Debrief staff to determine how tools are perceived; whether frustration is setting in; (3) examine work products created using tools for quality; (4) determine time required to create work products using tools vs. manual approach—look for anomalies.
Management: Assumes that tools are notworking. Determine reasons why. If staff is untrained, then provide one-to-one mentoring/training using staff experts and vendor trainers (budget for this contingency). If training is OK but tools don’t work, then consider alternative work product generation approaches using a semi-automated approach, e.g., word processors and graphical tool and a stripped down version of required models.
35.11 Here is one example of a Table 35.2 risk rewritten using the CTC format.
Given that the size estimate be significantly lower than the size of the actual system being built then there is a concern that (possibly) only 60% of the project will be completed within the time allocated for the completion of the project.
35.12 Cost = 18 components x 100 LOC/Component x $16 / LOC = $28,800
RE = P x C = .6 x $28,800 = $17,280
35.13If a risk is high probability, high impact, but the project team cannot do anything to mitigate, monitor, or manage it; it should not appear in the risk table. For example, if the company goes out of business in the middle of the project, the impact is catastrophic. Assume the probability of this is high, given outside business pressures. The software project team will likely have no control over the outcome.
35.14Any application area in which human life can be affected by defects is a candidate: medical equipment, avionics, power plant control (especially nuclear), automobile control systems, and radar. In addition, systems that are involved in national security and systems that facilitate major economic transactions are also candidates.