Software risk management

IMRAN HUSSAIN mmmttt88@yahoo.com MS(SE)

Abstract
There are several challenges and dilemmas in applying effective software risk management processes, particularly in into software development organizations. This paper presents the principles of risk management; explain risk based methodologies and approaches. These software risk management approaches and methodologies indicates identification , analyzing and controlling risks and planning for mitigation strategies during entire life cycle of software development and maintenance particularly in size, structure and technology. It provides a patient, discipline and organized environment for proactive decision-making to mitigate go wrong and give foreseen information for handling undesirable risks.

INTRODUCTION
Software project environment is full of multiplicity of risk inherent which caused project failure. Standish Group reports (Standish Group, 2012) shows that 14% and 42% of project get successful by using waterfall and agile process model respectively but they do not meet cost and . schedule requirements and approximately 57% and 49%of software project are challenged by the adoption of waterfall and agile process models respectively where as 29% and only 9% software project failed by the use of waterfall and agile process models respectively.

In the light of this failure report which significantly alarming thus waterfall process model relatively goes in danger zone for adoption point of view. Because software risk management manages risk in a project through processes, methods and tools in software engineering practice.

risk
technical issues manageme nt issues

McManus report (2004)

Other studies shows that 15 to 35% of software projects are cancelled Software products , and operational failures. Boehm defines four major reasons for implementing software risk management [Boehm-89]: 1. Avoiding software project disasters, including run away budgets and schedules, defect-ridden software products, and operational failures. 2. Avoiding rework caused by erroneous, missing, or ambiguous requirements, design or code, which typically consumes 40-50% of the total cost of software development. 3. Avoiding overkill with detection and prevention techniques in areas of minimal or no risk. 4. Stimulating a win-win software solution where the customer receives the product they need and the vendor makes the profits they expect.

McManus report (2004) shows that about 65% of the project unsuccessfulness on account of management issues, and 35% by technical issues. Planning methodologies, project structure customer buy-in, project resources and inadequate risk management are encapsulated in managerial issues. Whereas technical issues consists of poor software design, improper technical reviews, unsatisfied development, and testing methodologies. Jiang and Klein (1999) explore risk of different classes will affect budget, duration, system performance and user satisfaction.

RISK
The dictionary meaning of risk is the possibility of loss or injury the term risk is universally used in different contextual domains. In the software world, risk is an important issue often referring to the sources of danger to software development, acquisition, procurement, or maintenance. Risks are simply potential problems. Risk cannot be completely eliminated from a software project, but we can manage them a risk is the precursor to a problem; the probability that, at any given point in the software life cycle, the predicted goals cannot be achieved within available resources. There are many classical definitions of risk, some of which represent below:
2

A possible future event that, if it occurs, will lead to an undesirable outcome (Leishman and VanBuren, 2003). Risk refers to a possibility of loss, the loss itself, or is associated with that possibility (Kontio, 2001).

HOW TO BORN RISK?

There are many sources which may effect to the enterprise internally and externally. These gigantic forces cannot be overcome completely; therefore the enterprise has to make awareness about these risks on its all paradigm of IT budgets. Risk can be classified into systematic and unsystematic risk [1]. External risks are categorized as systematic risk. It exists probably in each and every organization. Examples of these types of risks are natural disaster , fire , virus, hacking and power loss. Whereas unsystematic risk is a type of total risk which is unusual and special to an organization. these types of risks are human interaction, loss of data, misuse of data, inside attack, application errors, malfunction of equipment. Systematic and unsystematic risks further classified into market risk, interest rate risk and purchasing power risk into systematic risk category and business risk, financial risk and default risk into unsystematic risk category.

SOFTWARE RISK MANAGEMENT

Risk management is a root to manage risks. Risk management mitigates the uncertainties related to certain events and reduces the impact of unwanted tasks. It has its roots in probability theory.

RISK MANAGEMENT MODELS

There are several types of risk management models such that IRMF which describes impact and likelihood along the axes in cells against particular risk management action. The shaded portion of cells shows the action related to the particular person or authority concerned.

This model facilitates assessment against the risk impact and likelihood. IRMF model can also be used for helping in the area or
3

ideas in the context of opportunity seeking and experimentation or innovation--the idea behind it is that an organization wants to make investments proper and to the likely return on those investments.

SEI RISK MANAGEMENT MODEL

In addition to this model a popular risk management model which is developed by the software engineering institute (SEI) as shown in figure.

reducing strategies for software risk management. The approach rely on, amongst many other elements, the risk taxonomy, which comprise of constructs used for organizing risk facts. The taxonomy assess in providing with an instrument that is called a questionnaire to draw out different category of risks. The entire taxonomy of risks can be found in (Higuera and Haimes, 1996), and is elimentated from here. The taxonomy has classification of risks into categories such as Requirements risks, Design risks, Coding and testing risks, Contract risks, Resource risks, and so on. The whole SEI risk management model circulates around the following activities describes below: Identify: identification of risk before they occur is very necessary so that they cannot bring adversely affect to your project. You must develop such environment in which everyone can express ones point of views and conducting quality reviews throughout all phases of a project are simple and common techniques for identifying risks. Analyze: Analysis is another form of risk data into risk decision-making information. It consists of prioritizing, reviewing and selecting the most critical risks to identify. The Software Risk Evaluation (SRE) Team analyzes each identified risk in terms of its consequence on cost, size, schedule, performance, structure and product quality. Plan: planning is the core part of these activities which moves or turns risk information into decision-making actions. Planning as the core part for developing actions to indentifying individual risks, prioritizing risk actions and creating a Risk Management Plan. The major key point of risk action planning is to consider the future consequences of a decision made in present. Track: tracking is the procedure of monitoring the status of risk in a project and
4

Software risk management paradigm SEI provided comprehensive facility to assess risk through risk management framework activities consist of the following three groups of exercise: Software Risk Evaluation, Continuous Risk Management, and Team Risk Management. The Software Risk Evaluation thought related to the identification, analysis, communication, and

in accordance with take powerful action for mitigate the chance of risk affects. Control: Risk control depends on project management processes to control risk action plans, brings improvement for variations from plans, respond to triggering events, and make better risk management processes. Risk control activities are documented in the Risk Management Plan. Communicate: Communication take place throughout all the phases of risk management. Without effective Communication, no risk management approach can be capable of working successful.

used in our study. These criteria deal with the fundamental aspects of risk management. We then created a questionnaire those questions were based on (1) these criteria, (2) Software engineering institute (SEI) risk management process model [1], and (3) a template of risk management information . The questionnaire is described in SectionB and presented in Figure. In the fourth step, we used colleagues to make the interviews. The students those are attending advanced international software engineering course. In Overall, 11 interviews were conducted with representatives from 13 different software organizations. Finally, in the fifth step, we analyzed the answers. Questionnaire section B

RESEARCH METHOD
This section describes the research method taken during our study. Section A describes the research steps. Section B describes the questionnaire used in our study. Finally, Section C discusses the sampling and validity. Research Steps section A During the first step, we studied a set of risk management process models as described above To achieve and cover the all dimension of the risk management domain, we chose publications of renowned Industrial and academic institutions, including: (1)Karachi nuclear power plant (KANUPP). 2) Karachi institute of nuclear power engineering and (3) various investigations made by individual researchers Our goal was to create as comprehensive a model as possible covering all the issues as suggested by the risk management models. In third step, we resolute and determined the comparison criteria to be

The questionnaire used in our study consisted of four parts. We have seen there in Table 1, in the beginning part, Section A Introduction, because we need about the background information related to the interviewees and their organizations. In the second part, Section B-Risk Management, we investigated the state of risk management practice within the organizations studied. In the third part Section C Development and Risk Management Process Integration, we examine whether and how the organizations managed to integrate risk management with their constructing and development processes. At last, in the fourth part, Agile vs Traditional Processes, we explore integration of risk management with agile methods. All these parts constitute a foundation for our evaluation criteria, to be examined in Section IV. The questionnaire used in this study was semi-structured and closed-ended. The main mission was to get required information and limited liberty to respondents to answer in their own terms. Such type of interviewing has a positive effect in a sense that while
5

SECTION (A) INTRODUCTION 1. 2. 3. 4. NAME.. Organization/institute .. E-MAIL CELL NUMBER . Address Strength OF YOUR Organization DATE A) 19. Yes B) No

Risk information sheets (RIS) are never an acceptable substitute for a full risk mitigation, monitoring, and management (RMMM) plan. A) True B) False

20.

Do you think risk management process is impotent? A) Yes B) No

5. 6. 7.

SECTION (B) RISK MANAGEMENT 8. An effective risk management plan will need to address which of the following issues? B) risk monitoring A) risk avoidance

SECTION (C) RISK MANAGEMENT PROCESS INTEGRATION AND GROWTH 21. Do you conduct risk management on the business planning level? A) 22. C) contingency A) high B) C) 23. low medium Yes B) No

What is the ratio of outcome of business phase?

9.

planning D) all of the above Does your organization identify risks? A) Yes B) No An effective risk management plan will need to address which of the A) high following issues? B) risk monitoring A) risk avoidance C) C) all of the above A) high contingency 24. low

How well defined is the project scope in degree? B) medium

10.

. What is the level of confidence in the accuracy of the budget estimate? B) C) low medium

11.

planning D) In wich way you handle risks?

A) 12.

reactive

B) proactive 25. Hazard analysis focuses on the identification and assessment of potential hazards that can cause A) project termination B) schedule

What is the possibility of budget overrun? A) Not likely B) moderately

13.

possible C) Highly probable If you have different types of risks, do you have models specialized to each risk type? A) Yes B) No Risk information sheets (RIS) are never an acceptable substitute for a full risk mitigation, monitoring, and management (RMMM) plan? A) Yes B) No Hazard analysis focuses on the identification and assessment of potential hazards that can cause

26. 27.

slippage C) external problems D) entire system to fail What is the level of confidence in the accuracy of the schedule estimate? A) high C) minimal B) moderate

14.

28. 15.

What is the life expectancy for the system being developed? A) More than 10 years C) 5 to 10 years B) Less than 2 years

A)

project termination C) external problems

B)

schedule slippage D) entire

29.

Proactive risk management is sometimes described as fire fighting. Do you agree? A) Yes B) No

system to 30. 16. What is the degree of flexibility in the schedule and completion date?

Do you conduct risk management on the engineering planning level? A) Yes B) No

A) 17.

Moderate flexibility

B)

Limited flexibility

Do you have any risk management process owner? A) Yes B) No

18.

Do you record risk and risk management activity?

Interviewing, one may elicit more information about the studied domain. Its drawback however is the fact that the interviewer must possess a good understanding with the domain studied, in order to acceptably response to irrelevant answers. Due to that fact that we used colleagues in our investigation, we go with the risk that have some answers may be difficult to understand. For the avoidance of misunderstanding, three preventive actions were taken. At first we presented our risk management model in detail to the colleagues. Second one is that detailed directives regarding the expected replies, and possible follow-up queries were inserted into the questionnaire. The goal of the interview, the questions and the questionnaire design were also described and discussed in class together with the colleagues. Third, the interviewees were asked to provide their names and contact details as shows in questionnaire figure to allow us to contact them with follow-up questions. Sampling and Validity section c Convenience sampling is the type of non probability sampling . it is the most common of all sampling techniques. With convenience sampling, the samples are selected because they are accessible to the researcher. It is easy to chosen simply because they are easy to recruit. This technique is considered easiest, favorable, cheapest, easy to sort out and least time consuming. organizations show willing for an interview, the students were allowed to choose just any organization (large/medium/small and/or private/ government) in any country. The only requirement was that the organizations

studied should have a risk management process in place. process integration of 39 organization or departments
other partial full 0 10 20 30 process integration of 39 organization and departments

Process integration of 13X3 organization or departments. (Questionnaire base) Twenty organization or departments have integrated in their development processes with risk management, eight organizations or department have partially integrated them, and another eleven have as separate processes to them.

CONCLUSION
We observe in this paper and have studied the industrial practice of risk management and its integration with software development in 3 software organizations or departments Regarding the industrial current status of risk management process, on the basis of our serve though questionnaire few organizations have implemented the entire process. The substantial great numbers of organizations studied mainly apply the initial phases of Risk Identification and Risk Analysis. Besides this, organizations have responded us with an important feedback for identifying several drawbacks in the current risk management models. There is need for extend their work in future.

REFERENCES
[1] Software Engineering Institute Web site: http://www.sei.cmu.edu/risk Ahern D., Clouse A., Turner R., CMMI Distilled. 2nd Ed. Addison-Wesley, Boston, MA, 2005. Nyfjord and Kajko-Mattsson, Degree of Agility in Pre-Implementation Process Phases. Accepted at the 19th Australian Software Engineering Conference, Australia, March 2008. Software Engineering (9th Edition) by Ian Sommerville (Mar 13, 2010) Software Engineering: A Practitioner's Approach by Roger S. Pressman (Jan 20, 2009) Software Engineering: Theory and Practice (4th Edition) by Shari Lawrence Pfleeger and Joanne M. Atlee (Feb 27, 2009) Research papers 1.An Industrial Case Study of Implementing Software Risk Management
By Bernd Freimut, Susanne Hartkopf, Jyrki Kontio Werner Kobitzsch

3. Software Risk Management by 4. DIFFERENT TECHNIQUES FOR RISK MANAGEMENT IN SOFTWARE ENGINEERING: A REVIEW by Vinod Kumar ,Uma Kumar and Subhas C. Misra 5.Risk Assessment by Ronald P. Higuera and Yacov Y. Haimes 6.Techniques for Software Development by Rasmita Dash and Rajashree Dash 7.State of Software Risk Management Practice By Mira Kajko-Mattsson and Jaana Nyfjord 8.Software Risk Management: Importance and Practices By Abdullah Al Murad Chowdhury and Shamsul Arefeen

2.Project risk management: lessons learned from software development environment