IJRIT International Journal of Research in Information Technology, Volume 1, Issue 12, October, 2013, Pg. 323-328
International Journal of Research in Information Technology (IJRIT)
www.ijrit.com
ISSN2001-5569
Requirements and Implementation of Risk Management Activities and Tools in Software Project Management 1
Swati Sharma, 2 Parul Singh, 3 Pooja Dang
Dronacharya College of Engineering, Khentawas, Gurgaon, Haryana Corresponding Mail: -
[email protected] ______________________________________________________________________________ Abstract The paper presents various risk management activity which can be use during the development of a software project. It also explains various software testing tools and activities which help to minimize the software project management risk. Software development is a very expensive task and software developer face lot of difficulties during the development and management of a software project. Some time risk is so severe that can increase the software development time, effort and cost. The goal of any project is develop the project within a limited time, effort and budget so this paper describes the risk management activity which can help to minimize all the risks. Keywords Software Project, Risk management, Software Tool, Effort, Risk, Budget ______________________________________________________________________________
Swati Sharma, IJRIT
323
Introduction Software development is inherently risky, however the need to adapt processes intended for larger organizations introduces a new element of risk. Software projects are exposed to various types of risks where risk is understood as a possibility of loss of budget, development effort or may be failure of a whole project. Essential features of a risk management are that it finds out the negative consequences that can affect the development of the project. The risks related to the whole project are defined in relation to project goals. The goal of any project is to deliver, in time and within the budget constraints, a product that meets client’s needs and expectations. The essential factors of the project success are the quality, the time and the budget[1] In the essential project aspects, the lack of risk management results in schedule slippage, budget overrun, unsatisfactory quality of the product In the essential project aspects, the lack of risk management Present software projects are often facing expanding and changing client demands and are put under schedule pressure. The systems are growing in size and become increasingly complex. To shorten the development time the systems are built out of reused (but often not reusable) components. The personnel turnover is high and the size and diversity of project groups are growing. Consequently, despite of the progress in technology, the software engineering project management still faces similar problems as thirty years ago. Risk always involves two characteristics (I) Uncertainty- this risk may or not happen; that is, there are no 100% probable risk. (II) Loss-if the risk becomes a reality, unwanted consequences or losses will occur. It can be manage by software engineering practice with processes, methods and tools for managing risks in a project. Risk analysis and management are a series of steps [3] that helps a software team to understand and manage uncertainty. Many problems can plague a software project. A risk is a potential problem—it might happen, it might not. But, regardless of the outcome, it’s a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur. Risk management means that we change our attitude towards risks. A project without risk management faces serious problems only after the risks came to the surface as a material fact (the deadline is not met, the budget is overrun, the quality is poor). Then, the only thing to do is to strive to minimize the negative influence of the consequences of those facts on the project. 2. Risk Categorization Risk is divided into five main categories which are explain below. 2.1Project risks They threatened the project plan. If they become real, it is likely that the project schedule will slip and that costs will increase
Swati Sharma, IJRIT
324
2.2Technical risks They threaten the quality and timeliness of the software to be produced If they become real, implementation may become difficult or impossible 2.3Business risks They threaten the viability of the software to be built If they become real, they jeopardize the project or the product 2.3.1 Sub-categories of Business risks Market risk – building an excellent product or system that no one really wants Strategic risk – building a product that no longer fits into the overall business strategy for the company Sales risk – building a product that the sales force doesn't understand how to sell Management risk – losing the support of senior management due to a change in focus or a change in people Budget risk – losing budgetary or personnel commitment 2.4 Known risks Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date) 2.5 Predictable risks Those risks that are extrapolated from past project experience (e.g., past turnover) Unpredictable risks Those risks that can and do occur, but are extremely difficult to identify in advance 3. Reactive vs. Proactive Risk Strategies Reactive risk strategies The majority of software teams and managers rely on this approach Nothing is done about risks until something goes wrong The team then flies into action in an attempt to correct the problem rapidly (fire fighting) Crisis management is the choice of management techniques Proactive risk strategies Steps for risk management are followed (see next slide) Primary objective is to avoid risk and to have a contingency plan in place to handle unavoidable risks in a controlled and effective manner 4. Need for Risk Management Software development involves New technology Challenging or unknown requirements tight schedules [4]. All these make the software project prone to several types of risk. After the risks are identified, Risk management develops plans for mitigating risk before they sale the projects. 4.1 Steps involved in implementing risk management Identify new risks Evaluate new risks Classify new risks Prioritize new risks Planning Risk mitigation
Swati Sharma, IJRIT
325
Tracking Risks and mitigation plans Reviewing and adjusting mitigation plans
Framework of risk management 4.2 Identify new risks Write down the risk and make them visible to all. A risk can be caused by Diminished quality of the product Increased costs Delayed completion Total program failure Don’t depend on managers to recognize and articulate all possible problems. Make a large list of 100 or more analyzed and priority-ordered risk statements 4.3Evaluate new risks A risk should be quantified by its probability and impact. Assess the probability of a future event and estimate its cost. Don’t make a detailed quantitative assessment of probability and impact for one risk. An effective way is to avoid early quantification of impact and probability unless the risk has a significant impact on the program. 4.4 Classify new risks Classify or group risks statements in to categories based on shared characteristics can help us solve global risks. With a single risk, A configuration manager might see an aspect that affects configuration management. A software engineer might see an aspect that affects component quality. A project manager might see an aspect that affects the customer.
Swati Sharma, IJRIT
326
5.5 Prioritize new risks The organization should deal with the most important risks first and should decide how many of these it has the resources to mitigate. A group’s weekly prioritization of the top n risks results in constant thrashing and some risks move on and off the priority list such that the action on the most important risk will be taken first to avoid the sabotage of the whole project. 4.6 Planning Risk mitigation To mitigate a risk, the goal and constraints must be known. We can use problem solving and analytical techniques to develop strategies and guide our actions. Resolution can be a single action item or a complex, long range prototyping effort. Mitigation plans can be action item lists or the equivalent of task plans 4.7Tracking Risks and mitigation plans Documentation of risks like in spreadsheets summarizes the project’s risks well. For important risks, we may need backup data. Complex tracking reports are needed for critical risks. An effective portrayal of risk exposure vs time is the mitigation status report, to monitor mitigation progress on critical risk. 4.8 Reviewing and adjusting mitigation plans Information is only useful if it’s accessible and easy to understand. It’s very effective to use electronic databases to implement and support risk management. It requires extra effort and time to set up a database when compared to paper-based risk documentation systems. Integrating risk data with other types of data such as problem and safety reports will present risk data in a meaningful way to users. 4.9 Principle of risk management Maintain a global perspective View software risks within the context of a system and the business problem that is intended to solve Take a forward-looking view Think about risks that may arise in the future; establish contingency plans Encourage open communication Encourage all stakeholders and users to point out risks at any time Integrate risk management Integrate the consideration of risk into the software process Emphasize a continuous process of risk management Modify identified risks as more becomes known and add new risks as better insight is achieved Develop a shared product vision A shared vision by all stakeholders facilitates better risk identification and assessment Encourage teamwork when managing risk Pool the skills and experience of all stakeholders when conducting risk management activities
Swati Sharma, IJRIT
327
5. Risk Management Tools. Capital asset pricing model – Used to determine the appropriate required rate of return of an asset, if that asset is added to an already well diversified portfolio, based on nondiversifiable risk. IBM Open Pages GRC Platform – Integrated enterprise governance, risk and compliance solution that includes modules for operational risk management, policy and compliance management, financial controls management, IT governance, and internal audit management[5] Probabilistic risk assessment (PRA, also called Probability Consequence or Probability Impact Model) – Model based upon single-point estimates of probability of occurrence, initiating event frequency, and recovery success (e.g., human intervention) of a specific consequence (e.g., cost or schedule delay). Risk register – A project planning and organizational risk assessment tool. It is often referred to as a Risk Log. EPRI Risk and Reliability Workstation (CAFTA) -- Widely used tool to create and quantify core damage frequency numbers at American commercial nuclear power plants. Systems Analysis Programs for Hands-on Integrated Reliability Evaluations (SAPHIRE) – A probabilistic risk and reliability assessment software tool. CONCLUSION In this paper we have proposed many risk management activities and testing tools which are very useful for risk management. So that these activities avoids the future risk of project management and testing tools save the huge amount of testing time, person effort and money of the organization. An effective risk management avoids future problems rather than solving the current ones.
REFERENCES [1]. R. L. Van Scoy, Software Development Risk: Opportunity, Not Problem, SEI report CMU/SEI-92-TR-30, Carnegie Mellon University, Pittsburgh PA, and September 1992. [2]. F. P. Brooks, Jr., The Mythical Man-Month, Essays on Software Engineering, Anniversary Edition, Addison Wesley Longman Inc., 1995 [3] Roger S. Pressman, “Software engineering: a practitioner’s approach”, 5th ed, McGraw-hill. [4]. Managing commitments and risks: challenges in distributed agile development Kontio, J.; Hoglund, M.Ryden,J.; Abrahamsson,P.; Software Engineering, 2004. ICSE 2004. Proceedings. 26th International Conference on , 23-28 May 2004 Pages:732 – 733 [5] http://en.wikipedia.org/wiki/Risk_management_tools
Swati Sharma, IJRIT
328
