TERM PAPER

Subject Name Principles of Software Engineering Subject Code CSE314

RISK IDENTIFICATION
Submitted to Lec. Harjinder Kaur

Submitted By-

Jivtesh Singh Ahuja Roll No - RD3804B52 Class-MCA204 Sem(2) Section D3804 Reg. No. 10812519

Acknowledgement
This is to certify that I Jivtesh Singh Ahuja student of M.C.A. section D3804 Roll No. RD3804B52 has made this term paper. Under this term paper we are given different topics. This term paper could not have been written better without Lec. Harjinder Kaur who not only served as my supervisor but also encouraged and challenged me throughout my academic program and patiently guide me through the process, never accepting less than my best efforts. I also want to thank to my classmates for encouraging and supporting my academic efforts.

Table of Contents

S.No.
1 2 3 4 5 6 7 8 9 10 INTRODUCTION WHAT IS RISK

Content

Page Num ber

4 5 9 11 14 15 18 19 21 25

TYPES OF RISK IN SOFTWARE DEVELOPMENT RISK MANAGEMENT RISK IDENTIFICATION METHOD FOR IDENTIFYING RISKS ASSESSING OVERALL PROJECT RISK RISK COMPONENTS AND DRIVERS RISK PROJECTION BIBLIOGRAPHY AND REFERENCES

Chapter 1

Introduction

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software

The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the current "software crisis" at the time. Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, cheaper, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much work and debate around what software engineering actually is, and if it deserves the title engineering. It has grown organically out of the limitations of viewing software as just programming. Software development is a term sometimes preferred by practitioners in the industry who view software engineering as too heavy-handed and constrictive to the malleable process of creating software.

Chapter 2

What is Risk

Risk is a concept that denotes the precise probability of specific eventualities. Technically, the 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. There are many definitions of risk that vary by specific application and situational context. One is that risk is an issue, which can be avoided or mitigated (wherein an issue is a potential problem that has to be fixed now.) Risk is described both qualitatively and quantitatively. In some texts risk is described as a situation which would lead to negative consequences. Qualitatively, risk is proportional to both the expected losses which may be caused by an event and to the probability of this event. Greater loss and greater event likelihood result in a greater overall risk. Rather, a risk is something thatmight occur in the future: a possibility, not a certainty. To be technicallyprecise, there are two factors that comprise a risk: 1. Probability or likelihood that it will occur 2. Loss resulting from its occurrence. Risk is a part of any activity and can never be eliminated, nor can all risks ever be known. Risk in itself is not bad; risk is essential to progress, and failure is often a key part of learning. But we must learn to balance the possible negative consequences of risk against the potential benets of its associated opportunity.

The success of software development and/or acquisition projects is not guaranteed. The aim of any software project is to provide the problem stakeholders with a satisfactory solution within the schedule and budget limits. The risk of poor product quality and schedule or budget overruns is high which is confirmed by a number of cancelled, delayed or overpaid projects. Effective management of those risks is presently perceived as one of the most important areas of project management. Current practice of risk management is mostly based on the intuition and personal experience of project managers. The ongoing research effort aims at providing effective support of risk management activities, and in particular at providing for reusing the risk-related knowledge and experience gathered in earlier projects. A majority of the software projects commissioned never go into production. Software development fails to deliver, and fails to deliver value. The failure has huge economic and human impact. We need to find a new way to develop software. The basic problem with software development is risk- a problem that must be solved if the software development process is to be as reliable and as cost effective as other processes like building a house that we can consider to be reliable.

In engineering, the definition risk often simply is:

Or in more general terms:

REACTIVE / PROACTIVE RISK STRATEGIES

REACTIVE RISK STRATEGY: Reactive strategy monitors the Project for likely
risks. Resources are set aside to deal with them, should they become actual problems. More commonly, the software project team does nothing about risk until something goes wrong. Then, the team flies into action in an attempt to correct the problem rapidly. This is called Fire fighting mode. When this fails CRISIS MANAGEMENT takes over and by then the project is in really jeopardy.

PROACTIVE RISK STRATEGY:Proactive Risk Strategy begins long before

technical work is initiated. It involves with identifying all Potential Risks, Assessing the Probability of each Risks impacts, and Ranking the Risks by their Importance. Then the software team establishes a Plan for managing the Risk. This approach is considerably more intelligent strategy. The primary objective is to avoid Risk, but because not all risks can be avoided, the team works to develop a Contingency Plan that will enable the team to respond in a controlled and effective manner.

SOFTWARE RISKS

There has been considerable debate about the proper definition of Risk. However, there is a common agreement that Risk always involves two characteristics. 1. UNCERTAINTY (it may or may not happen) 2. LOSS (If risk becomes a reality, unwanted consequences or losses will occur) It is important to Quantity the level of uncertainty and the Degree of loss associated with each risk. To accomplish this different Categories of Risks are considered.

Chapter 3

Types of Risk in Software development

Technical Risk These risks may result from excessive constraints, lack of experience, poorly defined parameters, or dependencies on organizations outside the direct control of the project team.

Problems with language Project size (leading to Financial Risks and Schedule Risk ) Project functionality Platforms Methods, Standards, Processes

Management Risks

Lack of planning Lack of management experience and training Communications problems Organizational issues Lack of authority Control problems

Financial Risks

cash flow Capital and budgetary issues Return on investment constraints

Contractual and Legal Risks

Changing requirements Market-driven schedules Health & safety issues Government regulation Product warranty issues.

10

Personnel Risks

Staffing lags Experience and training problems Ethical and moral issues Staff conflicts Productivity issues Contractor Risk

Other Resource Risks

Unavailability or late delivery of equipment & supplies Inadequate tools Inadequate facilities Distributed locations Unavailability of computer resources

11

Chapter 4

Risk Management
Risk management is the area that tries to ensure that the impact of risks on cost, quality, and schedule is minimal. Like configuration management which minimize the impact of change, risk management minimize the impact of the risk. However risk management is generally done by the project management. Risk management can be considered as the dealing with the possibility and actual occurrence of those events that are not regular or commonly expected . E.g.The commonly monthly expected events, such as people joing on leave or some requirements changing, are handled by the project management. So according to it the risk management deals with events that are not infrequent, somewhat out of the control of the project manger and are large enough to justify the attention. Most project has a risk. The idea of the risk managent is to minimize the possibility of the risk materialization, if possible, of to minimize the effect of risk actually materializing. For example, when constructing a building, there is a risk that the building may later collapse due to the earthquake i.e. the possibility of the earthquake is the risk. If the building is the large residential complex, then the potential cost in case the earth risk materializes can be enormous. This risk can be reduced by shifting the complex to a zone that is not earthquake prompt. Alternatively, if this is not acceptable, then the effect of the risk materializing are reduced by suitably constructing the building. So the risk management hass to deal with the identifying the undesirable event that may occur, the probability of their occurring, and the loss if an undesirable evnt does occur. Once this is known the strategy can be formulated for either reducing the probability of the risk materializing or reducing the effect of the risk materializing.

12

So the element of the Risk Management paradigm as: Identify locate risks before they become problems and adversely affect the program. Analyze turn the raw risk data into decision making information. Plan turn the risk information into decisions and actions (both present and future). Track monitor the status of risks and actions taken against risks. Control correct for deviations from the planned risk actions. Communicate provide the feedback on the active risk activities, current risks, and emerging risks among the paradigm elements and within the program.

13

Risk Identification

Risk Assessment

Risk Analysis

Risk Prioritization

Risk Management

Risk Management Planning

Risk Control

Risk Resolution

Risk Monitoring

Risk Management Activities

14

Chapter 5

Risk identification

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. The risk identification method is the first step in a comprehensive and continuous risk management method being developed to enhance the probability of project success. Subsequent technical reports will address the analysis, planning, tracking, and control aspects of risk management while, throughout, addressing the issue of risk communication. There are two distinct types of risks for each of the categories that have been presented in generic risks and product-specific risks. Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. To identify product-specific risks, the project plan and the software statement of scope are examined and an answer to the following question is developed: "What special characteristics of this product may threaten our project plan?"

15

Chapter 6

Method for identifying risks

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: Product sizerisks associated with the overall size of the software to be built or modified. Business impactrisks associated with constraints imposed by management or the marketplace. Customer characteristicsrisks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definitionrisks associated with the degree to which the software process has been defined and is followed by the development organization. Development environmentrisks associated with the availability and quality of the tools to be used to build the product. Technology to be builtrisks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experiencerisks associated with the overall technical and project experience of the software engineers who will do the work.

16

The risk item checklist can be organized in different ways. Questions relevant to each of the topics can be answered for each software project. The answers to these questions allow the planner to estimate the impact of risk. A different risk item checklist format simply lists characteristics that are relevant to each generic subcategory. Finally, a set of risk components and drivers" are listed along with their probability of occurrence. Drivers for performance, support, cost, and schedule are discussed in answer to later questions.

A number of comprehensive checklists for software project risk have been proposed in the literature. These provide useful insight into generic risks for software projects and should be used whenever risk analysis and management is instituted. However, a relatively short list of questions can be used to provide a preliminary indication of whether a project is at risk.

17

Checklist outline view

18

Chapter 7

Assessing Overall Project Risk

These questions have derived from Risk data by surveying experienced software Project Managers in different part of the success of a Project:1) Have top Software and Customer Managers formally committed to support the Project? 2) Are End-users enthusiastically committed to the Project and the System/Product to be built? 3) Are requirements fully understood by Software Engineering team and their Customers? Have Customers been involved fully in the definition of requirements? Do End-users have realistic expectations? Is Project Scope stable? Does the Software Engineering team have the right mix of skills? Are Project requirements stable? 9) Does the Project team have experience with the technology to be implemented? 10) Is the number of People on the Project team adequate to do the job? 11) Do all Customer/user constituencies agree on the importance of the Project and on the requirements for the System/product to be built? If any one of these questions is answered negatively, Mitigation, Monitoring, and Management steps should be instituted without fail. (See RMMM Plan) The degree to which the Project is at Risk is directly proportional to the number of negative responses to these questions.

4) 5) 6) 7) 8)

19

Chapter 8

Risk Components and Drivers

The project manager identify the risk drivers that affect software risk components performance, cost, support, and schedule. In the context of this discussion, the risk components are defined in the following manner:

Performance riskthe degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost riskthe degree of uncertainty that the project budget will be maintained. Support riskthe degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Schedule riskthe degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

20

The impact of each risk driver on the risk component is divided into one of four impact categories negligible, marginal, critical, or catastrophic.

21

Chapter 9

RISK PROJECTION

Risk projection, also called risk estimation, attempts to rate each risk in two ways the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur.

The project planner, along with other managers and technical staff, performs four risk projection activities: (1) Establish a scale that reflects the perceived likelihood of a risk, (2) Delineate the consequences of the risk, (3) Estimate the impact of the risk on the project and the product, and (4) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

22

Developing a Risk Table

A risk table provides a project manager with a simple technique for risk projection. A sample risk table is illustrated as :

A project team begins by listing all risks (no matter how remote) in the first column of the table. This can be accomplished with the help of the risk item checklists Each risk is categorized in the second column. The probability of occurrence of each risk is entered in the next column of the table. The probability value for each risk can be estimated by team members individually. Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge. Next, the impact of each risk is assessed. Each risk component is assessed using the characterization presented, and an impact category is determined. The categories for each of the four risk componentsperformance, support, cost, and scheduleare averaged to determine an overall impact value. Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. This accomplishes first-order risk prioritization. The Project Manager then studies the Risk Table and defines a Cutoff line. This implies that only Risks that are above the Cutoff line will be given further attention. Risks below that Cut-off line are re-evaluated to accomplish the Second-Risk Order Prioritization.

23

Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur: 1. Its nature- The nature of the risk indicates the problems that are likely if it occurs. For example, a poorly defined external interface to customer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project. 2. Its scope - The scope of a risk combines the severity (just how serious is it?) with its overall distribution. 3. Its timing - the timing of a risk considers when and for how long the impact will be felt. In most cases, a project manager might want the bad news to occur as soon as possible, but in some cases, the longer the delay, the better.

24

RISK EXPOSURE

The following steps will have to be considered when determining the overall consequences of a Risk. 1. Determine the Average Probability of Occurrence Value for each Risk Component. 2. Determine the Impact for each Risk Component. 3. Complete the Risk Table and analyze the results. The Overall Risk Exposure is determined by using the following relationship.

RE= (P * C)
Where P = Probability of occurrence for a Risk C = Cost of the Project should the Risk occurs

25

Chapter 10

BIBLIOGRAPHY AND REFERENCES

Websites: http://en.wikipedia.org/wiki/Software_engineering http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/index.html http://www.rspa.com/spi/ http://leansoftwareengineering.com/

Books: Software Engineering by Roger S. Pressman

26