c


    c

   

 
  
    c

   
 
  


  

  


 
 !     !  
The goal of the risk mitigation, monitoring and management plan is to identify as
many 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 their
probability 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 is
more 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, and
management in order to produce a quality product. The quicker the risks can be
identified and avoided, the smaller the chances of having to face that particular
risk¶s consequence. The fewer consequences suffered as a result of good RMMM
plan, the better the product, and the smoother the development process.

" 

   #  

Each member of the organization will undertake risk management. The
development team will consistently be monitoring their progress and project
status as to identify present and future risks as quickly and accurately as possible.
With this said, the members who are not directly involved with the
implementation of the product will also need to keep their eyes open for any
possible risks that the development team did not spot. The responsibility of risk
management falls on each member of the organization.

$  

         %
!
Inability to work TI 85% 1
because of software
problems
TI 70% 1
Computer Crashes
Coding errors DE 90% 2
Absenteeism BU 50% 2
TI ± Technical Impact
BU - Business Impact Risk
DE - Development Environment Risk

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


ß

&c'  Inability to work because of software problems

à   

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.

à    

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.

à 


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.


&() 



à   

The cost associated with a computer crash resulting in a loss of data is crucial. A
computer crash itself is not crucial, but rather the loss of data. A loss of data will
result 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.

à    

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.

à 
 

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.

&'    

à   

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.

à    

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.

à 
 

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





&)'  c  


 à   

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.

à    

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.

à 
 

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.

 !
 StandardRMMM plan document is used to prepare RMMM document for
hospital automation software.