Aim: - Case study of RMMM plan for Hospital Automation software

Problem statement: - Prepare RMMM plan for Hospital Automation software development as if you are a member of Risk management team.

Theory: - 1. Scope and intent of RMMM activitiesThe goal of the risk mitigation, monitoring and management plan is to identify asmany potential risks as possible. The project will then be analyzed to determine any project-specific risks.When all risks have been identified, they will then be evaluated to determine theirprobability of occurrence, and how System will be affected if they do occur.Plans will then be made to avoid each risk, to track each risk to determine if it ismore or less likely to occur, and to plan for those risks should they occur.It is the organization’s responsibility to perform risk mitigation, monitoring, andmanagement in order to produce a quality product. The quicker the risks can beidentified and avoided, the smaller the chances of having to face that particularrisk’s consequence. The fewer consequences suffered as a result of good RMMMplan, the better the product, and the smoother the development process.

2. Risk management organizational roleEach member of the organization will undertake risk management. Thedevelopment team will consistently be monitoring their progress and projectstatus as to identify present and future risks as quickly and accurately as possible.With this said, the members who are not directly involved with theimplementation of the product will also need to keep their eyes open for anypossible risks that the development team did not spot. The responsibility of riskmanagement falls on each member of the organization.

3. Prepare a risk tableRisks Category Probability Impact Inability to work because of software problems

TI 85% 1

Computer CrashesTI 70% 1

Coding errors DE 90% 2

Absenteeism BU 50% 2

TI – Technical ImpactBU - Business Impact Risk DE - Development Environment Risk

Impact Values:1 – Catastrophic 2 – Critical 3 – Marginal 4 – Negligible

4. Prepare RMMM plan-

(A)Risk: Inability to work because of software problems

Mitigation

Software problems can be of various types such as bugs, viruses, worms, etc. Bugs trigger Type I and type II errors that can in turn have a wide variety of ripple effects, with varying levels of inconvenience to the user of the program. Some bugs have only a subtle effect on the program's functionality, and may thus lie undetected for a long time. More serious bugs may cause the program to crash or freeze leading to a denial of service. Others qualify as security bugs and might for example enable a malicious user to bypass access controls in order to obtain unauthorized privileges.

Monitoring

Usually, the most difficult part of debugging is finding the bug in the source code. Once it is found, correcting it is usually relatively easy. Programs known as debuggers exist to help programmers locate bugs by executing code line by line, watching variable values, and other features to observe program behavior. Without a debugger, code can be added so that messages or values can be written to a console (for example with printf in the C programming language) or to a window or log file to trace program execution or show values.

Management

It is common practice for software to be released with known bugs that are considered non-critical, that is, that do not affect most users' main experience with the product. While software products may, by definition, contain any number of unknown bugs, measurements during testing can provide an estimate of the number of likely bugs remaining; this becomes more reliable the longer a product is tested and developed ("if we had 200 bugs last week, we should have 100 this week"). Most big software projects maintain two lists of "known bugs"— those known to the software team, and those to be told to users. This is not dissimulation, but users are not concerned with the internal workings of the product. The second list informs users about bugs that are not fixed in the current release, or not fixed at all, and a workaround may be offered.

(B) Risk: Computer Crash

Mitigation

The cost associated with a computer crash resulting in a loss of data is crucial. Acomputer crash itself is not crucial, but rather the loss of data. A loss of data willresult in not being able to deliver the product to the customer. This will result in a not receiving a letter of acceptance from the customer. Without the letter of

Acceptance, the group will receive a failing grade for the course make multiple backup copies of the software in development and all documentation associated with it, in multiple locations.

Monitoring

When working on the product or documentation, the staff member should always be aware of the stability of the computing environment they’re working in. Any changes in the stability of the environment should be recognized and taken seriously.

Management

The lack of a stable-computing environment is extremely hazardous to a software development team. In the event that the computing environment is found unstable, the development team should cease work on that system until the environment is made stable again, or should move to a system that is stable and continue working there.

(C) Risk: Coding errors

Mitigation

As the staff working on the project is not expert in the programming language there is a high possibility of error occurrence and due to which the project may get delayed. Although the project may be completed it may cause some problem in the future. . As a result the organization is taking steps to hold training period for the staff.

Monitoring

While working on the project the programmer should be well aware of the basic programming commands. In monitoring the activities of the project, the runtime as well as compile time errors should be minimized.

Management

The lack of a programming knowledge is extremely hazardous to a software development team. In the event that the computing environment is found unstable, the development team should cease work on that system until the environment is well aware of the respective programming code, or should move to a s/w development team that is well aware of that particular programming code and continue working there

(D) Risk: Absenteeism

Mitigation

As the workers working on the project may have their personal reasons or helath issues because of which they may remain absent. Even heavy work pressures may lead to absenteeism of workers.

Monitoring

The development team members have different timetables and most of them also have part time jobs. This makes it a bit hard to locate meeting times that suit everyone. The team members of the development team have never been working together as a team. Because of this, there may be some conflicts that will happen among team members. 

Management

Workers should report in when they are unable to make it to work for any particular reason what so ever, so that we may keep a backup in his/hers place.Also they should be provided with paid leaves and for extra leves their salary should be deducted. Any conflict between the staff members should be resolved by the team leader.

Conclusion: - Standard RMMM plan document is used to prepare RMMM document for hospital automation software.