93 3.3 SOFTWARE RISK MANAGEMENT (SRM) Fig. 3.2 SRM is a process buit in five steps. The steps are: Identify Anayse Pan Track Resove The process is continuous in nature and handed dynamicay throughout ifecyce of deveopment. Figure 3.2 shows the SRM process mode. SRM Process Mode Identify Anayse Pan Monitor Resove 3.3.1 Identify Risk identification is a process to hande certain inputs that produce a set of outputs, namey, a ist of risks, their types and its importance in the context of the software proposed to be deveoped. The inputs are the degree of uncertainty on a number of features such as requirements, technoogy, peope aocation, insufficient domain and appication knowedge, concerns about ack of skis and knowhow, and issues regarding the technica and commercia aspects of the software deveopment. These inputs hep to identify the risks and their nature. In order to ensure that risk identification is compete, organisations deveop checkists that are used to identify the risks. Mature organisations aso maintain a risk database if they hande a number of sma and arge software deveopment projects. The checkists, risk database, and risk assessment forms are the faciitation in the identification process. The inputs mentioned so far are externa, arising out of software deveopment proposas. The other set of inputs that hep to identify and to some extent assess the risk are proposed resource aocations based on the software requirement specifications. The risk identification process begins with an assessment using the checkists. The assessment is best done when it is conducted as a participatory activity. The risk anayst conducts interviews with experienced personne who have worked earier in simiar software projects. Periodic meetings are conducted with persons to identify the risk. It shoud be noted that risk identification is not a one-time task undertaken at the beginning of the ife cyce; it is an exercise that continues ti the software is deivered satisfactoriy. Some risks, which were not perceived in first review, may emerge ater in the ife cyce.
94 Part I Basics of Software Engineering Once the risk is identified, its attributes, that is, the probabiity of occurrence and the oss arising out of risk are determined. Both these attributes are based on the subjective judgement of the concerned peope. This judgement may be supported by risk database and the experience of peope in the fied. The oss may not be monetary, but coud emerge in the form of adverse effects on software quaity, which incudes features ike fexibiity, maintainabiity, portabiity, reiabiity, reusabiity and so on. The Defence Systems Management Coege (DSMC), Fort Bevoir, VA, USA, provides a scae guideine to fix the probabiity of occurrence based on the response the risk anayst woud get in interviews and in review meetings. Figure 3.3 shows the suggested probabiity against the response to various questions. Fig. 3.3 Response versus Probabiity of Risk Occurrence Response Amost Certain Highy Likey Probabe Likey We beieve Better than even chance We doubt Improbabe Unikey Probaby not Litte chance Amost no chance Highy unikey Amost no chance 0 25 50 75 100% Probabiity The risk identification process not ony identifies the risk but aso determines attributes and communicates further to peope in the team. The key to successfu identification process is the use of checkists. One can use safey the SEI Software Risk Taxonomy as shown in Tabe 3.3. The SEI risk taxonomy is a structured checkist that organises known risks to specific eement attributes. The taxonomy is divided into three parts, namey, product engineering, deveopment environment and program constraints. Further, each part is subdivided into components. Each of these components is discussed for identification of an attribute determination. This exercise gives rise to a ist of risk statements with contextua information and detais of identification. For exampe, the risk anayst wi discuss stabiity of requirements, suitabiity of deveopment process and personne in terms of avaiabiity, capabiity and maturity. 3.3.2 Anayse and Assess Risk Risk Anaysis (RA) is a process that defines activities and methods to estimate and evauate risk. In estimation, the probabiity of occurrence is estimated and its consequence. In evauation, the risk options against certain criteria are discussed.
95 Tabe 3.3 SEI Software Risk Taxonomy The risk anaysis process begins with ist of risks obtained from the earier process of risk identification. Each risk from this ist is taken for estimation and evauation. To act on this step, the organisation needs an evauation criteria and the risk database. First, the probabiity and consequence is estimated and then the Risk Exposure (RE) determined. Risk Exposure = Probabiity Loss For exampe, the customer environment suggests that the stabiity of requirement specification is very ow. This is aso the experience of the project team with Product engineering Deveopment environment Program constraints 1. Requirements 1. Deveopment Process 1. Resources a. Stabiity a. Formaity a. Schedue b. Competeness b. Suitabiity b. Staff c. Carity c. Process contro c. Budget d. Vaidity d. Famiiarity d. Faciities e. Feasibiity e. Product contro 2. Contract f. Precedent 2. Deveopment system a. Type of contract g. Scae a. Capacity b. Restrictions 2. Design b. Suitabiity c. Dependencies a. Functionaity c. Usabiity 3. Project Interfaces b. Difficuty d. Famiiarity a. Customer c. Interfaces e. Reiabiity b. Associate Contractors d. Performance f. System support c. Subcontractors e. Testabiity g. Deiverabiity d. Prime contractor f. Hardware constraints 3. Management Process e. Corporate Management g. Non deveopmenta a. Panning f. Vendors software b. Project organisation g. Statutory Bodies 3. Code and Unit Test c. Management experience a. Feasibiity d. Project Interfaces b. Unit test 4. Management Methods c. Coding/ impe- a. Monitoring mentation b. Personne management 4. Integration and Test c. Quaity assurance a. Environment d. Configuration management b. Product 5. Work Environment c. System a. Quaity attitude 5. Engineering b. Co-operation Speciaities c. Communication a. Maintainabiity d. Morae b. Reiabiity c. Safety d. Security e. Human factors f. Specifications
96 Part I Basics of Software Engineering Tabe 3.4 Risk Severity by Risk Exposure and Time Frame this particuar customer. Hence, identified risk, a critica requirement may be missing or may change radicay. Based on the risk database and customer experience, probabiity is 0.50. The oss due to this risk occurrence is a waste of three man-month effort, amounting to a oss of Rs. 1.5 akhs. Hence, risk exposure is RE = 0.50 1.5 = 0.75 akhs Based on this criteria of risk exposure, it is determined whether it is ow, Moderate or high and considered against the time frame as short, medium and ong term. Both these attributes are evauated on common criteria known as risk severity. Tabe 3.4 shows the index of risk severity. Time Frame Risk Exposure Low Moderate High Short 5 2 1 Medium 7 4 3 Long 9 8 6 Source: Software Risk Management by Ean H. Ha Based on the risk severity criteria, the risks are prioritised for action. Index 1 for a short-term time frame and high-risk exposure is considered the highest risk severity. Index 9 is termed as the owest because of the ow exposure and ongterm time frame. When you evauate a risks by these criteria, they come under a common patform, irrespective of whether the risk is of project, product or process. At the end of risk anaysis, you get a prioritised risk ist with probabiity, risk exposure, and risk severity. This forms the basis for constructing a risk action pan for resoution. 3.3.3 Pan Risk The risk pan proposes various actions to dea with the risks identified and anaysed in the earier processes. The output of the process is the Risk Action Pan (RAP). RAP takes as input the Prioritised Risk List based on risk severity, and determines resoution strategies for each one on the ist. The risk resoution strategies suggested by Ean H. Ha a researcher and author of the book on Risk management are Risk Acceptance Risk Avoidance Risk Protection Risk Reduction Risk Research Risk Reserves Risk Transfer
97 Risk Acceptance: This strategy is chosen when you have no choice but to ive with risk and face the consequences. Risk Avoidance: This strategy is chosen to eiminate risk atogether or bypass it atogether. This strategy is chosen when you are in ose-ose situation. You wi dea with the sources of risk to avoid or eiminate them by management actions. Risk Protection: This strategy is chosen when there is a possibiity to reduce the probabiity of occurrence and the consequentia oss. For exampe, you may hire a temporary consutant to provide domain knowedge support or the skis required to reduce process deay and product risk. Risk Reduction: This strategy is chosen over and above risk protection. Based on a cost-benefit anaysis, the organisation may take such actions that risk incidence is reduced, giving rise to major reduction in the consequentia oss. Risk Research: This strategy is chosen to reduce the risk by seeking more information about it for better evauation, and aso to dea with it effectivey. The firm may, for exampe, conduct a proof of concept exercise or experiment to reduce the voatiity of the requirement specifications. Another exampe is that the organisation may seek more information from genuine resources on new products or the introduction of new technoogy. Based on this information, the index of severity wi be reduced, and the action pan changed accordingy. Risk Reserves: This strategy is chosen when the risk severity is ow but risk acceptance is not possibe. You buid a contingency pan to dea with this risk, in case risk occurs. You may provide extra sack in schedue, keep a reserve on ca, reserve funds in case required. Risk Transfer: This strategy is chosen when it is possibe to transfer the risk to somebody ese. You may choose outsourcing, subcontracting, buying a resource or too as a risk transfer strategy. Though the strategies discussed are six, they can be subsumed under three basic goas about the risk, as shown in Fig. 3.4. Fig. 3.4 Risk Strategy Structure Risk Strategy Structure Acceptance Prevention Transfer Acceptance Avoidance Reserves Protection Transfer Reduction Research
98 Part I Basics of Software Engineering Based on these strategies, a more concrete Risk Management action pan is designed for execution. 3.3.4 Track Risk The risk tracking process monitors risk occurrence, consequence, and exposure and provides triggers to act to resove the risk. The tracking process provides methods to keep watch on various activities that are ikey to be affected by the risk. These methods provide feedback on occurrence and impact, and trigger the predetermined action. The tracking process wi have a threshod norm for each risk beyond which the trigger wi generate the action to resove the risk by changing strategy or executing the proposed pan of action. The threshod coud be risk exposure or risk severity. The process has an input on risk status from the project team and from various MIS reports on software deveopment addressing the issues of schedue, cost, deivery and quaity. The output of the tracking process is evauation of exposure, severity and triggers to act where necessary. For exampe, risk of deay in deivery is a high severity risk. Assume that over 100 activities are invoved which affects the deivery. So, threshod for these activities is a deay of 15% in competion. If deay exceeds 15% it shoud be reported through MIS for action. It is important to note that risk occurrence is a possibiity at any time. The origina estimates and forecasts on occurrence, exposure, timing may change during the ife cyce, and tracking risk becomes an essentia activity in risk management system, and has to be made7 integrated activity in software deveopment pan. 3.3.5 Resove Risk Risk resoution process is defined where risk action pan forms the basis for resoving the risk using resoution toos and techniques and risk database. The objective of the process is to reduce the risk to eve of acceptabe risk. The output of the risk resoution process is ist of acceptabe Risk, Reduced rework and corrective actions. Risk resoution activities are Act on the trigger. Execute the risk action pan. Monitor the action pan and assess the new risk scenario. Contro the risk exposure through action, and/or action on deviation.
99 Tabe 3.5 RRP, Inputs and Outputs The skis required to resove risk are creativity and coaboration. Effective impementation of risk action pan cas for generation of new and innovative ideas. This cas for creativity in the project team. Further, the risk action pan impementation is not straight inear action process by an individua. It is a coaborative process, and not a process impementation in isoation. The fundamenta risk resoution strategy is to reduce uncertainty, gain additiona knowedge and draw upon the experience of others from interna and externa sources. Resoution of risk is not a structured method but a process where creativity and coaboration of team members are key success factors. Tabe 3.5 gives summary of the steps in the Risk Resoution Process (RRP). Process steps Inputs Outputs Identify Risk Uncertainty, ack of List of risk by category cass, knowedge, concerns, type and context issues, risk database Anayse Risk and Assess List of risks, risk database Risk ist with probabiity, oss, exposure, severity and prioritised risk ist Pan Risk for Resoution Prioritised risk ist deter- Risk action pan i.e. mining resoution strategies, conversion of strategy and its impementations into concrete steps for action Track Risk Risk status through MIS, Emergence of threshod risk threshods deviation, triggers to act measures and metrics on to update risk database Resove Risk Risk action pan and use Changing risk scenarios into of toos and techniques acceptabe risk and reduce risk exposure.