1.)Risk is a concept that denotes the precise probability of specific eventualities. Technically, the notion of risk is independent from the notion of value and, as such, eventualities may have both beneficial and adverse consequences. However, in general usage the convention is to focus only on potential negative impact to some characteristic of value that may arise from a future event.
Risk can be defined as “the threat or probability that an action or event will adversely or beneficially affect an organisation's ability to achieve its objectives”[1]. In simple terms risk is ‘Uncertainty of Outcome’, either from pursuing a future positive opportunity, or an existing negative threat in trying to achieve a current objective.
Risk can be defined as “the threat or probability that an action or event will adversely or beneficially affect an organisation's ability to achieve its objectives”[1]. In simple terms risk is ‘Uncertainty of Outcome’, either from pursuing a future positive opportunity, or an existing negative threat in trying to achieve a current objective.
2.)Risk Management Strategies include the following
Risk Avoidance
Risk Abatement
Risk Retention
Risk Transfer
Risk Allocation
Risk Avoidance is just that, avoiding the risk associated with a specific task, activity or project. Often, following the review of a contract, it is determined that a project is just too risky. The client may decide not to bid the work at all, or remove that element of the work from their bid, sometimes using an alternate deduct to delineate the exclusion.
Risk avoidance is strictly a business decision, and sometimes a very good strategy if construction documents are unclear, ambiguous or incomplete.
Risk Abatement is the process of combining loss prevention or loss control to minimize a risk. This risk management strategy serves to reduce the loss potential and decrease the frequency or severity of the loss. Risk abatement is preferably used in conjunction with other risk management strategies, since using this risk management method alone will not totally eliminate the risk.
Risk Retention is a good strategy only when it is impossible to transfer the risk. Or, based on an evaluation of the economic loss exposure, it is determined that the diminutive value placed on the risk can be safely absorbed. Another consideration in retaining a risk is when the probability of loss is so high that to transfer the risk, it would cost almost as much as the cost of the worst loss that could ever occur, i.e., if there is a high probability of loss, it may be best to retain the risk in lieu of transferring it.
Risk Transfer is the shifting of the risk burden from one party to another. This can be done several ways, but is usually done through conventional insurance as a risk transfer mechanism, and through the use of contract indemnification provisions.Risk Allocation is the sharing of the risk burden with other parties. This is usually based on a business decision when a client realizes that the cost of doing a project is too large and needs to spread the economic risk with another firm. Also, when a client lacks a specific competency that is a requirement of the contract, e.g., design capability for a design-build project. A typical example of using a risk allocation strategy is in the formation of a joint venture.
3.)Software Risk
Staff Turnover- Experienced staff will leave the project before it is finished.
Management Change- There will be a change of organisational management with different priorities.
Hardware Unavailability- Hardware that essential for the project will not be delivered on scheduled.
Requirement Change- There will be a large number of change on the requirements than anticipated
Specifition Delays- Specification essential interfaces are not available on schedule.
Size underestimate- The size of the system has been underestimated
CASE tool underperformance- CASE tools which support the project do not perform as anticipated.
Technology Change- The under lying on which the system is built is supersaled by the technology.
Product Competition- A cmpetitive product is market before the system is completed.
4.) As a member of the team, I would ask first my teamates whether they want to work overtime eventhough being not paid. If I was going to ask if I would accept it, my answer would be YES but considering the factors I would really think it twice and I will check the time management of each one of us.
5.Eventhough it was not field of specification, I would accept the offer, because despite the fact that I dont have that skill in managing but I can contribute also in technical. And also I want to try y managing skill if I can. There is no problem if I accept the offer. In fact, its an advantage to my part because I was offered that kind of oppurtunity.
Ian Sommerville,SOFTWARE ENGINEERING,7th edition, Chapter 5
