SOFTWARE RISK MANAGEMENT

Submitted in partial fulfillment of the requirements for the award of the degree of

Master Of Computer Application (2008-2011)

Guided by: Mrs Manisha Kaushik Lecturer

Submitted by: Abhijit Kumar Eno-0501594408

RUKMINI DEVI INSTITUTE OF ADVANCED STUDIUES (Aff. to Guru Gobind Singh Indraprastha University) Madhuban Chowk, New Delhi 85

ABSTRACT
The emerging discipline of software risk management is described or defined as an attempt to formulize the object oriented correlates of success into a readily application set of principles and practices. its objectives are to identify, address and eliminate risk items before they become either threat to successful software operation or major sources of software rework This paper address and evolutionary process currently taking places in software engineering: the shift from hardware to software, where the role of software engineering is increasing and becoming more central in system integration. This shift also markedly affects the sources of risk that are introduced through out the life cycle of a systems development its requirements, specifications, architecture process testing and end product. Risk is commonly defined as a measure of the probability and severity of adverse see effects. Software technical risk is defined as a measure of the probability and severity of adverse effects inherent in the development of software. Consequently, risk assessment and management, as a process, will more and more assume the role of an overall cross-functional system integration agent. Evaluating the changes that ought to take place in the response to this shift in this pattern leads to two challenges. One is the need to role of a new breed of software engineers/system integrators .the other is the need to develop new and appropriate matrices for software technical risk effective systems must be accounted along with an assessment of most risks associated with the system.

Furthermore, for software systems integration is not only the integration of

components, but is also: an understanding of the functionality that emerges from the integration, indeed, when two or more software components are integrated, they often deliver more than the sum of what each was intended to deliver: this integration adds synergy and enhanced functionality. In particular, the thesis advanced in this paper is that the process of risk assessment and management is an imperative for successful system integrations: this is especially true for software-intensive systems

INTRODUCTION

Prospering in todays software marketplace means that high-risk projects are precisely the ones we need to undertake. Formal risk management makes sure we go into such projects with our eyes open, so we know what kind of things could go wrong, and we have done our best to make sure that those factors wont prevent success of the project.

A risk is often specified in terms of an event

or circumstances and the consequences

of an event and their likelihood. Risk may have a positive or negative impact. The term risk management is applied in a number of diverse disciplines like in the fields of statistics, economics, and Psychology, social sciences, biology, engineering, toxicology, system analysis, Operational research, and decision theory to make a few have been addressing the field of risk management. Kloman summarized the meaning of risk management in the context of a number of different disciplines in an article for risk analysis:

What is risk management? To many social analysis ,politicians and academics it is the management of environmental and nuclear risk ,those technology generated macro risks that appear to threaten our existence , to bankers and financial officers it is the sophisticated use of such technique as currency hedging and interest swaps. To insurance buyers and sellers it is coordination of insurable risks and the reduction of insurance costs. To hospital administrators it may mean quality assurance. To safety professionals it is reducing accidents and injuries.

What is risk?
A simple definition of a risk is a problem that could cause some loss or threaten the success of a project, but which happened yet. These potential problems might have an adverse impact on the cost, schedule or technical success of the project, the quality of our software products, or project team morale. We need to differentiate risks, as potential problems from the current problems facing the projects, because different approaches are taken for addressing these two kinds of issues. For example, a staff shortage because you havent been able to hire people with right technical skills is current problem, but the threat of your top technical people being hired away by the competition is a risk.

RISK CAN BE MEASURED BY IMPACTS X PROBABILITY

All areas in system development are potential sources software risk. Since it involves technology, hardware, software, people, cost, and schedule

TECHNOLOGY

HARDWARE

SOFTWARE

SYSTEM
PEOPLE SCHEDULE

COST

Fig of Risk with-in a system

Software technical risk can be defined as a measure of the probability and severity of

adverse effects inherent in the development of the software that does not meet its intended functions and performance requirements. The need to manage risk increase with system complexity. Figure 2. Demonstrates this concept by indicating that as the complexity of the system increase, both technical and non-technical (cost and schedule) risk increases. There is an increasing need for more systematic methods and tools to supplement individual knowledge, judgment, and experience

Why Software Security Risk Management Matters

In less than thirty years, IT has grown from a province of largely academic concern to a driving force in world commerce. This trend, which started with the advent of distributed computing architectures in the early 1980s, accelerated dramatically with the rise of Web-based computing in the 1990s. Today, doing business without a Web-based sales channel even if only to supplement bricks-and-mortar operations is virtually inconceivable. With the rise of IT-enabled business has come an explosion of demand for IT products to support people, process and technology throughout the enterprise. These include: protocols, Web browsers, Web servers, application servers, database servers, virtualization servers, storage servers, storage attached networks, network devices, the myriad tools which support the management of these products and the hundreds of thousands of applications which automate the business processes of buying, selling and performing work. The growth and importance of IT security has paralleled this rise in importance of IT

as a business enabler and competitive differentiator such that today, the rubric IT security has come to represent all that guarantees IT will fulfill its promise to transform the way business is done. Along the way, the concept of security has grown from an initial guarantee of continuous IT availability to a set of much broader guarantees: data confidentiality and integrity, identity protection and even operational efficiency as it relates to business continuity. What is often overlooked amid this phenomenal growth of IT and IT security is the software that lies at the heart of every IT product, every IT device and every IT application. Software code, written by software developers, is what ensures that every IT device and every software application does what it is supposed to do including carrying out its security functions.

In other words, the whole edifice of enterprise IT is only as secure as the secure software development foundations on which it is built.

Reasons for Lack of Progress The .com boom was a false perception of success: Companies were not concerned about risks; only opportunities. Investors were uninterested in conservative, low-risk investments. The wrong risk management techniques were being used: Simple techniques (checklists, scoring tables, complex calculation tools) deployed in 1990s were not necessarily based on sound theories, good assumptions, or accurate mathematics. Industry practitioners may have felt that spending time on risk management was not costeffective. Risk management was too bureaucratic: Numerous report templates and standards were defined, and many lengthy reports produced, but not necessarily read or acted upon. Therefore, risk management created high overhead cost while producing little of value. Risk management was too standard: Many risk management approaches/tools aimed to make their use easier by standardizing on some aspects of their models. Risks often valued only through money, calendar or effort impacts. Similar checklists are applied to large defense contracts and small start-up companies. Realities are much more complex than this. Risk management was not transparent: Many risk management methods/tools use complex calculations and forms to document/analyze risk information. Little attention was paid to make sure all decision-makers understood the process and results. Since they didnt understand them,

Proposed New Agenda Business attitudes in software companies need to take both risk and opportunities into account

Biased and unsound software risk management methods should be replaced by better methods

Software risk management needs to be made cost effective and easy, while still based on sound principles

Software risk management needs to be application or situation specific. There are no silver bullets or one size fits all solutions.

Risk management methods must emphasize communication and understandability of results

Reasons for Lack of Progress in Software Risk Management [Kontio, 2002]

Risk Example

A company has introduced objectoriented (OO) technology into its organization by selecting a well-defined project X with hard schedule constraints to pilot the use of technology. Although many X project personnel were familiar with the OO concept, it has not been part of their development process, and they have had very little experience and training in the technologies application. It is taking project personnel longer than expected to climb the learning curve. Some personnel are concerned, for example that the module implemented to date might be too in efficient to satisfy project X performance requirement. The risk is : Given the lack of OO technology experience , there is a possibility that the product will not meet performance or functionality requirements within the

defined schedule

NON-RISK EXAMPLE

Another company is developing a flight control system. During integration testing the flight control system becomes unstable because processing of the control function is not quick enough during a specific planned sequence

RISK MANAGEMENT
Generally, Risk management is the process of measuring, or accessing risk and developing strategies to manage it . Risk management is the process of identifying, addressing and eliminating these potential problems before they can damage our project. Strategies include transferring the risk to another party , avoiding the risk, reducing the negative effects of the risk and accepting some or all of the consequences of a particular risk . Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death and lawsuits) In ideal risk management, a prioritization process is followed whereby the risk the greatest loss and greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later.

Intangible risk management identifies a new type of risk a risk that has 100% probability of occurring but is ignored by the organization due to a lack of identification ability, For example, a) Knowledge risk occurs when deficient knowledge is applied b) Relationship risk occurs when collaboration ineffectiveness occurs c) Process-engagement risk occurs when operational ineffectiveness occurs

These risk directly reduce the productivity of knowledge workers, decrease cost effectiveness, probability, service, quality, reputation, brand value and earning quality. Intangible risk management allows risk management to create immediate value from the identification and reduction of risks that reduce productivity. Risk management also faces difficulties allocating resources. Resources spent on risk management could have minimize spending while maximizing the reduction of the negative effects of risks

SEI Risk Statement

For a risk to be understandable, it must be expressed clearly. Such statement must include A description of the current conditions that may lead to the loss A description of the loss

Klomans definition of Risk management

Risk management is a discipline for living with possibility that future events may cause adverse effects. Symptoms that an organization is not effectively practicing risk management include:i. ii. iii. iv. A continual state of project instability Constant fire fighting. Multiple schedule slippages because of reducing surprise factors And constantly operating in a high stress, crisis management role.

Formal risk management greatly improves the likelihood of successful project completion, and it reduces the potential negative consequences of those risks that cannot be avoided

Objectives Of Risk Management

The developed software risk methodologies have three fundamentally different objectives: i. ii. iii. Risk prevention Risk mitigation and correction Ensuring safe system failure

Why Manage Risk Formally ?

A formal risk management process provides a number of benefits to the project team

1. It gives us a structured mechanism to provide visibility into threats to protect success .by considering the potential impact of each item , we can make sure we focus on controlling the most sever risks first. 2. A team approach allows the various project stake holders to collaboratively address their shared risks and to assign responsibility for risk mitigation to the most appropriate individuals 3. We can combine the risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize the problems 4. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed 5. The net result of these activities is to help avoid preventable surprises late in the project and therefore improve the chance of meeting our commitments 6. Members of the organization can pool their experience and identifies opportunities and to control our most common risks, through education, process improvement and application of improved software engineering and management techniques

Risk and Uncertainty

Much risk is attributable to uncertainty about the things we sometimes pretend are under control. Its what we dont know that can hurt us Uncertainty is a normal and unavoidable characteristic of most software pretend are under control. Its what we dont know what can hurt us. Cause of Uncertainty It can result from the continually increasing complexity of the products we create. Lack of practical knowledge about the software development technique and tools we are using presents an additional source of uncertainty

Controlling risk partly means reducing uncertainty. Reducing uncertainty has a

cost. We need to balance such costs against the potential cost as we could incur of the risk is not addressed. It may not be cost effective to reduce uncertainty too much. For example , if we are concerned about the utility of an essential component of our product on time, we could engage multiple subcontractors to increase the likelihood that at least one will come through on schedule .Thats an expensive remedy for problem that may not even exist

Risk is Created by Failing to Deal with Change

In the context of software engineering, development and software project management, risk can be defined as the possibility of suffering a diminished level of success (loss) within a softwaredependent development program. The prospect of loss is such that the application of the selected theories, principles, or techniques may fail to yield the right software products. [1] The potential loss and the association of risk to the program involves a value judgment as to the potential impact of risk to the outcome. The term loss, danger, hazard, and harm, all of which reflect a negative perception, involve at least a relative assessment of value. [2] Various definitions of risk state that uncertainty expressed as a probability is involved with risk. Uncertainty involves both the description and measurement of uncertainties.
[2]

In addition, the nonlinear, nondeterministic character of the dynamics of the

[3]

environment also contributes to un-certainty.

Uncertainty also arises from the

inability to measure or describe exactly the circum-stances associated with risk. Uncertainty collectively forms the kinematic and dynamic characteris-tics of the environment as it evolves with time. The interrelationship of uncertainty and time is evidenced in the probability of the outcome of future events.
[4]

It is the management of this uncertainty through risk

mitigation that is a critical success factor in an IT project.

Three Myths of IT Project Management

IT projects traditionally use formal management processes for the acquisition or development, de-ployment, and operation that emphasize planning in depth. This approach organizes work into phases seperated by decision points. Supporters of this approach emphasize that changes made early in the project can be less expensive than changes made late in the project. In the past this approach has been called waterfall.
[5]

The waterfall approach contains

several er-roneous assumptions that negatively impact IT projects:

Planning It is not humanly possible to produce a plan so that its implementation is merely a matter of executing a defined set of tasks.

Plans for complex projects rarely turn out to be good enough for this to occur.

Unanticipated problems are the norm rather than the exception.

Change It is not possible to protect against late changes.

All businesses face late changing competitive environments.

Typical Software Risks

We need to rely on the past experience and strong knowledge of contemporary software engineering and management practices to control those risk we are most concerned about. Caper Jones has identified the top five risk factors that threaten projects in different application sectors. Table 1illisustrate those factors and the approximate percentage of projects to which they apply in the management information system? (MIS) and commercial software sectors.

Project Sector MIS

Commercial

Risk factor Creeping user requirement Excessive schedule pressure Low quality Cost overruns Inadequate Config. control Inadequate user documentation

% of Project at Risk 80% 65% 60% 55% 50% 70%

Low user satisfaction Excessive time to market Harmful Competitive actions Litigation expense

55% 50% 45% 30%

1). Dependencies
Many risks arise because of dependencies our project has outside agencies or factors. We cannot usually control there external dependencies, so mitigation strategies may involved contingency plans to acquire a necessary component from a second source or working with the source of the dependency to maintain good visibility into status and detect any looming problems.

Here are some typical dependency-related risk factors: Customer-furnished items or information. Internal & external subcontractor relationships Inter-component or inter group dependencies Availability of trained, experienced people. Reuse of one project to the next

2) Requirement Issues
Many projects face uncertainty and turmoil around the products requirements.

If we dont control requirements-related risk factors, we might either build the wrong product or build the right product badly. To avoid them one has to become familiar with established requirement gathering and management practices. There are some risk factors: Lack of clear product vision Lack of agreement on product requirements Unprioritized requirements New market with uncertain needs New applications with uncertain requirements Rapidly changing requirements Ineffective requirements change management process Inadequate impact analysis of requirement change

3) Management issues
Management people may also have weakness but they dont show them

Some of the risk factors related to them are: Inadequate planning and task identification Inadequate visibility into actual project status Unclear project ownership and decision making Unrealistic commitments made, sometimes for wrong reasons. Managers or customers with unrealistic expectations Staff personality conflicts

Poor communication

4) Lack of knowledge
The rapid rate of change of software technologies, and the increasing shortage of skilled staff, mean that our project team may not have the skills we need to be successful.

The key is to recognize the risk areas enough so that we can take the appropriate preventive actions such as obtaining training, hiring consultants and bringing the right people together on the project team.

These factors might apply to team Inadequate training Poor understanding of methods, tools and techniques Inadequate application domain experience New technologies or development methods Ineffective, poorly documented or neglected processes

5) Other risk factors

Some other areas you should include these:

Unavailability of development or testing equipment and facilities Inability to acquire resources with critical skills Turnover of essential personnel Unachievable performance requirements Problems with language translations and product internationalization Technical approaches that may not work.

Steps in risk management process

1). Establish the context
Establishing the context include planning the reminder of the process and mapping out the scope of the exercise , the identity and objectives of stake holders, the basic upon which risks will be evaluated and defining a framework for the process and agenda for identification and analysis of risk involved in the process.

2.) Identification after establishing the context, the next step in the process of managing risk is to identify Source analysis: risk sources may be internal or external to the system that is the target of risk management. Examples of risk resource are: stake holders of a project, employees of a company or the weather over an airport. Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat

of accidents and casualties, the threats nay exist with various entities most important with stake holders, customers and legislative bodies such as government.

When either source or problem is known the events that a source may trigger or the events that can lead to the problem can be investigated. For example: stake holders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate causalities. The chosen methods of identifying the risks may depend on the culture, industry practice and compliance. The identification methods are formed by template or the development of templates for identifying source, problem or event. Common risk identification methods are : Objective-based risk identification organizations and project teams have objectives. any event that may endanger achieving an objective partly or completely is identified as risk Scenario-based risk identification: in scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an object, or an analysis of the interaction of forces in , for example, a market battle. Any event that triggers an undesired scenario alternative is identified as risk. Taxonomy-based risk identification: the taxonomy in taxonomy based risk identification is a breakdown of possible risk resources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks

Common risk checking in several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation.

3) Assessment Once the task have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence .In the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan.

Difficulties in risk assessment The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Evaluating the severity of the impact is often quite difficult for immaterial assets. asset valuation is another question that needs to be addresses. Thus, best educated options and available statistics are the primary sources of information. Risk assessment should produce such information for the management of the organization that primary risks are easy to understand and that the risk management decisions may be prioritized.

Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is:

Rate of occurrence X impact of the event= risk

Last research has shown that the financial benefits of risk management are less dependent on the formula used but more dependent on the frequency and how risk management is performed.

In business it is imperative to be able to present the findings of risk assessments in financial terms. Robert Courtney Jr.(IBM,1970) proposed a formula for presenting risks in financial terms

The Courtney formula was accepted as the official risk analysis method for the US govt agencies

The formula proposes calculation of ALE(Annualized Loss of Expectancy) and compares the expected loss value to the security control implementation costs (cost benefits analysis)

Potential Risk Treatments

Once risk have been identified and assessed, all techniques to manage the risk fall into one or more of these major categories, Dorfman, 1997) Avoidance

Reduction (or mitigation) Acceptance (or retention) Transfer

Ideal use of these strategies may not be possible. Some of them may involve tradeoffs that are not acceptable to the organization or person making the risk management decisions

1) Risk avoidance Includes not performing an activity that could risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplane was to be hijacked.

Avoidance may seem the answer to all risks, but avoiding risks also means Loosing out on the potential gain that accepting (retaining) the risk of loss avoids the possibility of earning profits.

2) Risk reduction
Involves methods that reduce the severity of the loss. Examples include sprinklers designed to put out a fire to risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Modern software development methodologies reduce the risk by developing

and delivering software incrementally. A current trend in software development, headed by the extreme programming community, is to reduce the size of increments to the smallest size possible, sometimes as little as one week is allocated to an increment.

3) Risk Retention
Involves accepting the loss when it occurs. Example self-insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained.

4) Risk Transfer
Means causing another party to accept the risk, typically by contract For example:-insurance is one type of risk transfer that uses contracts. Some ways of managing risk fall into multiple categories

5) Create the plan

a) Decide on the combination of methods to be used for each risk. Each risk management decision should be recorded and approved by the appropriate level of management. b) For example , a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks c) The risk management plan should propose applicable and effective security

controls for managing the risks, for example , an observed high risk of computer viruses could be mitigated by acquiring and implementing anti-virus software. d) a good management plan should contain a schedule for control implementation and responsible persons for this actions

6). Implementation a) Follow all of the planned methods for mitigating the effect of the risks.

b) For example:-purchase insurance polices for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entitys goals, reduce others and retain the rest

7) Review and evaluation of the plan Initial risk management plans will never be perfect. Practice , experience and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced. Risk analysis result and management plans should be updated periodically. There are two primary reasons for this: 1) To evaluate whether the previously selected security controls are still applicable and effective and 2) To evaluate the possible risk level changes in the business environment. for example, information risks are a good example of rapidly changing business environment

Risk management Approaches

All organization can select one of five possible approaches to dealing with risks [McConnell, 1996] Risk management is the application of appropriate tools and procedures to contain risk within acceptable limits; Risk management consists of several sub disciplines. Risk assessment is the process of examine a project and identifying areas of potential risk Risk identification can be facilitated with the help of a checklist of common risk areas for software projects or by examining the contents of an organizational database of identified risks and mitigation strategies( both successful and unsuccessful). Risk analysis involves examing how project outcomes might change with modification of risk input variables

Risk prioritization helps the project focus on its most severe risks by assessing the risk exposure. Exposure is the product of the probability of incurring a loss due to risk and the potential magnitude of that loss. This prioritization can be done in a quantitative way by estimating the probability (0.1-1.0) and relative loss, on a scale of 1 to 10. Multiplying these factors together provide an estimation of the risk exposure due to each risk item ,which can run from 0.1(dont give it another thought) through 10 (stand back, here it comes!).

The higher the exposure, the more aggressively the risk should be tackled. It may be the easier to simply estimate both probability and impact as high, medium or low. Those items having at least one dimension rated as high are the ones to worry about first. Risk Avoidance is one way to deal with risk: dont do the risky things! You may avoid risks by not understanding certain projects, or by replying on proven rather than cutting edge technologies. Risk control is the process of managing risks to achieve the desired outcomes Risk management planning produces a plan for dealing with significant risk, including mitigation approaches, owners and timelines Risk monitoring involves tracking your progress towards resolving each item. Finally, Risk resolution is execution of the plans for dealing with each risk

Quality Factors & Risk

In the book Assessment and control of software risk , Jones describes the results of his experience with formal assessment of software development. Using Software productivity Research(SPR) or Software Engineering Institute methods to review projects in several hundred enterprises.

These software produced by these projects are sorted into six major generic classes. Management Information System(MIS): accounting and claim systems Systems software projects such as operating system , telecommunication or other systems which control physical devices Commercial Off The Shelf (COTS) development projects where products are leased/sold to end users Military software projects that are constrained to follow MILSPEC Contract/Out sourced software projects(civilian domain) where bulk of software is produced by contact personnel versus employees of the client organization End user software projects where the intended users versus professional programming staff developed the software. Over 100 risk factors were observed within these programs. Few projects have more

than 15 risk factors at any time, but many have 6 simultaneously. Analysis of risk patterns from these assessments indicates that elements of significant risk are not the same across all the software domains. These lists contain the top risk factors, followed by their occurrence in the sample-assessed programs. Those items, which are directly or indirectly influenced by the quality assurance, program, or impact the quality software issues are shown in bold

MIS:
Creeping user requirements (80%) Excessive schedule pressure (65%) Low Quality (60%) Cost overruns (55%) Inadequate Configuration Control (50)%

Low Quality is defined as delivered software which either does not work at all, or which fails repeatedly in operation. Low quality of MIS results from normally things: 1) Inadequate defect removal such as failing to use inspections and carrying out testing in a casual or unprofessional fashion: and 2) Inadequate defect prevention such as failing to use standard techniques like Joint Application Design(JAD) or Information Engineering(IE) and sometimes failing to produce adequate specifications for the project.

Systems Software Risk:

Long schedules (70%) Inadequate cost estimating (65%) Excessive paper-work (60%) Error prone modules (50%) Cancelled projects (35%)

Excessive paper work has no exact definition, but paperwork can be considered to be excessive under the following conditions: a) More than 50 discrete documents types are produced. b) The cost of paperwork approaches or exceeds 50% of the total software project expenses. military software is the magnitude of paperwork production, with most of the paperwork appearing to be redundant or overlarge for the work at hand.(Note: a more subtle derivative problem that underlies excessive paperwork: to date , there has been no published literature on the optimum quantity, volume ,structure , or style of the set of paper documents that surround software projects.)

Commercial Software Risks

Inadequate user documentation (70%) Low user Satisfaction (55%) Excessive time to market (50%) Harmful competitive actions (45%) Litigation expense (40%)

Inadequate user documentation is defined as user information which is incomplete, unclear, wrong, or in convenient. User information includes on-line help and published material. This is the most widespread problem of the commercial s/w world. This problem can be traced to the following factors: Technical writing is such a comparatively scare skill. User manuals normally inadequate: o Documenting the first release of any new software package is notoriously difficult; o Some vendors cant afford or dont use component technical writers and illustrators; o The state of the art of S/W user documentation is still primitive and evolving. Low user satisfaction means clients are displeased with one or more of the following factors (as of 1993, some of these problems occurred on more than half of the commercially-marketed software): Low quality Inadequate functionality Complex or arcane command structures Steep learning curves Troublesome installation procedures Poor service or Customer support Excessive utilization or monopolization of disk space or other hardware components by the software.

Military Software

MILSPEC are fairly rigorous standard and ensure reasonable consistency from project to project, they also create a number of very expensive problems and create risks in their own right. Excessive paperwork (90%) Low productivity (85%) Long schedules (75%) Creeping user requirement (70%) Unused or unusable software (45%)

Excessive paperwork-large military projects routinely create up to 100 discrete document types and more than 6 pages of paper per function point. This paperwork, in all forms, eats up 53% of the total cost of military software projects. While Jones acknowledges some paperwork adds value and rigor to process; however, most appears to be redundant. He also observed its tougher to delete from military standard s than to add military standards Unused or unusable software is defined as software projects which, when delivered, are in fact not used by the intended user community. This is common to government software in general and the military software in particular. This tendency is due partly to long time span to complete military projects, such that the intended users have changed jobs or the jobs themselves have changed to the point where the software has little to no utility. Additionally, some of the hardware for which the S/W was created has become obsolete. Litigation surrounding contract awards are further extending this long project time, which is on the increase.

Contract or outsourced S/W risks

High maintenance costs (60%) Friction between contractor and client personnel (50%) Creeping user requirements (45%) Unanticipated acceptance criteria (30%) Legal ownership of S/W and deliverables (20%)

Maintenance costs are defined as projects where annual maintenance costs for defects repairs and minor updates are notably higher than U.S norms and where the amount of existing software which one person can maintain is notably lower than U.S norms. Unanticipated acceptance criteria are defined as new and sometimes stringent criteria levied on a contractor by a client as a condition of product acceptance or payment of funds, outside the scope of the initial contract or agreement. Examples of unanticipated criteria can include very stringent quality or performance targets for the software, or the need to retroactively specify or document the software. This situation can result from a failure to establish criteria early in the contract , or can be due to hard feelings on part of client that the work was not satisfactorily performed. This can result in damage to the project, client contractor relationship and in extreme cases litigation or contract termination.

End-user S/W risks

Nontransferable applications (80%) Hidden errors (65%)

Unmaintainable software (60%) Redundant applications (50%) Legal ownership of software and deliverables (20%)

Hidden errors are defined as logical or programming errors that are latent within an end user application without the knowledge of the author or anyone else. This is extremely common due to lack of formal reviews, testing, audits, or QA activity.

Risk Management n Beoehmis SIX Steps

As Jones assessments show, quality assurance activities do pose a direct or indirect risk to the software development process. Current software risk management has been adapted from concepts, practices, and principles, which has been successfully used within other engineering and manufacturing areas. This objective of software risk management is to identify, address , and eliminate potential elements of risk before they become either threats to successful software operation or major sources of software rework. Such threats are stated in terms of I risk exposure, I risk impact or i risk factor, I regardless of the term, it is defined by the relationship of the probability of an unsatisfactory outcome for a particular item and the loss to the affected players if the outcome is unsatisfactory. (this relationship can be displayed by a family of probability versus loss curves) . A decision tree is constructed showing the combined risk exposure for each decision option, where combined risk exposure is the sum of individual risk exposures obtained from specified probabilities of occurrence. This decision tree provides a numeric discriminator between the various options as well as facilitates sensitivity analyses of the preferred option to the risk exposure parameters.

Such analysis is of particular benefit where the occurrence probabilities and loss counts are not well enough known to permit precise analysis. Boehm lays out a six step risk management process consisting of two primary steps each having three subsidiary steps as means of implementing the concept in practice. Boehm further recommends a number of techniques appropriate to implement each primary and subsidiary step. The first step is risk assessment, which consists of : Risk identification, which identifies specific project risk items that are likely to endanger programs chances of success. Risk analysis , which determines the probabilities of individual and consolidated loss probabilities and costs for each items. Risk prioritization produces a ranked ordering of risk items that were identified and analyzed

Once a prioritized listing of project risk items has been developed, the second step, risk management is initiated. This step used to bring these risk items under control, consists of: Risk management planning which outlines how each individual item of risk will be addressed and how individual risk plans are integrated into the overall project management plan. Risk resolution in which implemented actions or activities either eliminated or resolve the risk involved with particular item and Risk monitoring, where the project progress towards resolving risk items or taking corrective action is tracked

Application of Risk Management to Quality Factors

As we noted in the Quality Factors And Risk section of this paper, several generic classes of software development either directly or indirectly suffered from quality or software assurance related problems, as well as factors causing these problems. In this section, we will propose some techniques that can help control, mitigate, or prevent these risks

Element: Creeping User Requirements: Risk Mitigation Techniques

Use of prototypes Use of JADS for requirement creation in MIS domain. Use of Information Engineering (I.E) methodologies for requirements creation- again, used primarily in the MIS domain.

Use of functional metrices to monitor requirements growth. Since metrices are normally qualifies during requirement phase , research now underway to couple and automate requirements gathering process and metrices creation. Now appears technically feasible to build requirements automation tools built around tables of common functions and features. Advantages of such tools: add speed and rigor requirements gathering, but feed data to both function point enumerators and cost estimators- could also feed into CASE, data modeling and design tools.

New techniques base contract on number of function points to be delivered and estimated cost per function point. This will force the user to recognize that requirements creep comes at a financial as well as schedule cost.

Element: Low Quality and Error Prone modules Risk mitigation techniques: Quality control on critical path to schedule reduction and cost control. Four classes of technologies that have proven to be effective for software quality control.

Quality estimation and reliability estimation tools. Quality/

reliability estimation tools are relatively new to market (only 6 commercial

grade tools in 1993) used by less than 10% of all software development managers

Defect prevention methods. Defect prevention includes all technologies

which can reduce the chances of making mistakes or errors and includes (a) any of the structured analysis and design techniques, (b) prototypes (c) high level and object oriented languages, (d) rigorous usage of structured coding techniques for procedural languages,(e) the Quality Function Deployment (QFD) approach, (f) the TQM approach , (g) SQA departments and (h) clean room development methods.

Defect removal methods. Defect removal methods include design

reviews, structured walkthroughs, formal codes inspections, correctness proofs, and all forms of testing. Formal review and Inspections have the highest measured defect removal efficiencies of any form of defect removal, and are in fact used by all the U,S quality leaders, testing works best if carried out by trained specialists in a formal manner and

Quality measurement programs. Jones noted that all U.S leaders in

software quality control have established full quality measurement programs. One of the newest extensions of functional metrices is in the quality domain. The older lines of the code metrices were so ambiguous and paradoxical for measuring requirements, design and documentation error levels that there was essentially no literature on many important quality topics. Function points were used in 1991 to establish U.S national quality average or military systems and MIS projects. As of 1993 functional metrices are also being used to measure and predict the number of test cases and test runs for S/W projects

Risk Management Can Be Your Friend

Risk management can be helpful in number of ways: The skillful project manager will use risk management as a techniques for raising the awareness of conditions that could cause their project to go down the tubes Consider a project that begins with an unclear product vision and a lack of customer involvement. The project manager will spot this situation as posing potential risks, and will document them in the risk management plan. Early in the projects life , the impact of this situation may not be too severe. However, if time continues to pass and the lack of product vision and customer involvement are not improved, the potential threat to the project will steadily rise By reviewing the risk plan periodically, the project manager can adjust their probability and /or impact of these risks. They may rise to the top ten, and can be brought to the attention of senior managers or other stake holders who are in position to either stimulate corrective actions, or make a conscious business

decision to proceed in spite of the risks. We are keeping our eyes open and making informed decisions, even if we cant control every adverse condition facing the project

Learning from the past

While we cannot predict exactly which of the many threats to our projects might come to pass, most of us can do better job of learning from the previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management strategies on our projects, also keeps records of our risk management activities for future references. Try these suggestions: Record the results of even informal risk assessments, to capture the thinking of the participants on each project. Keep records of the mitigation strategies attempted for each of the risks you chose to pursue, noting which approaches worked well and which did not pay off. Conduct post-project reviews to identify the unanticipated problems that arose. Should you have been blindsided in any case? Do you think these some problems might occur on other projects? If so add them to your growing checklist of potential risk factors that the next project can think about.

Anything you can do to improve your ability to avoid or minimize previous problems on future projects will improve your companys business success and reduce the chaos and frustration that reduces the quality of work life in so many software organizations.

Limitations
If risks are improperly assessed and prioritized, time can be wasted in dealing with the risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur. Prioritizing too highly the risk management processes could keep on organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete

Other Type Of Risk Management

Enterprise risk management(ERM):- It refers to the methods and processes used by the organization to manage risks (or seize opportunities) related to the achievement of their objective. ERM provides a framework for risk management, which typically involves identifying a particular events or circumstances relevant to the organizations objectives (risks and opportunities), accessing them in terms of likelihood and magnitude of impact, determining a response strategy, and monitoring progress. By identifying and proactively addressing risks and opportunities, business enterprises protect and create value for their stake holders, including owners, customers, regulators and society overall. ERM can also be described as a risk-based approach to managing an enterprise , integrating concepts of strategic planning and internal control. ERM evolving to address the needs of various stakeholders, who want to understand the broad spectrum of risks facing complex organization to ensure they are appropriately managed. Regulators and debt rating agencies have increased their security on the risk management processes of companies.

Operational Risk Management:- in business, term operational risk management is the oversight of many forms of day to day operational risk including the risk of loss resulting from inadequate or failed internal process, people and systems or from natural events. Operational risk does not include market risk or credit risk.

Risk Management Software

Risk management is the identification and evaluation of risks to an organizationincluding risks to its existence, profits and reputation- and the acceptance, elimination, controlling or mitigation of the risk and effects of the risks.

There are main two factors determining the importance of a particular risks: Probability-The enhance that a particular adverse circumstances will come about. Assessing the probability event is a good part of determining the overall risk

Cost- The price you will have to pay if an adverse event occurs. Balancing these two factors is the main way in which risk management software can help you assess your best course of action. If you have a risk in which is very probable, but has only a low cost, it may not take as high priority as a less likely occurrence which has a very high

cost. Risk management can be costly business. If you try and take account of all possible risks and allocate resources to remove them or mitigate against them, you will waste those resources if the risky events dont happen. The ideal management of risk is one, which allocates as few resources as possible, which still reducing the risks by maximum amount.

There are four main ways of reducing the Risks: Risk avoidance- dont do something which bight be the risky. This is an obvious way to reduce the risk, but it also reduces the possibility of gains. Risk reduction-Put measures in place to act against the risk. For example install a burglar alarm to reduce the risk of robbery in a building Risk retention- Accept the consequences of a particular risk . Normally only suitable for low level risks, it can be more cost effective than insuring against them. For example, accepting excess charge on a typical car insurance. Risk transfer- getting somebody else to take the risk. The most obvious example is taking out insurance, but you may also be able to arrange risk transfer by writing it into a contract with, for instance, a subcontractor. Risk management- Software can help you make decisions on all four forms of risk management by showing you which risks are the most important and how likely they are to occur. By using techniques such as Monte Carlo analysis, you can also determine the likely cost of particular risk.

Syntex: - The leader in the technologies and practice of Operation management.

Syntex management systems provides software and services that help companies protect worker health and safety, avoid devastating accidents, protect the environment, and cut costs. The worlds leading companies use our flagship software product, Syntex IMPACT enterprise, wither in a single-site locations or in worldwide deployments Syntex IMPACT enterprise supports our customers operational integrity initiatives. These initiatives are included in what is known today as Enterprise Risk management, Operational Risk management and Enterprise Loss prevention. By deploying our software, our customers save millions of dollars while at the same time improving Furthermore, IMPACT Enterprise helps companies maintain critical regulatory compliance , such as environmental and OSHA regulations, while facilitating the companies internal management systems, the international organization for

standardizations management system standards, and the American Chemistry Councils Responsible Care management system elements. It also facilitates the certification process of programs such as Occupational Safety and Health Administrators Voluntary Protection Programs, Star and Merit and many others

Enterprise and Operational Risk Management Syntex is a pioneer and leader in the practice and technology of Enterprise risk management. Many companies today-especially those with complex operations-Have Quality, Health, safety and Environmental initiatives, with the added emphasis today of security. Syntex has unequaled expertise for turning continuous improvement strategies into repeatable practices and policies using the power of enterprise computing. From the beginning, we have applied easy to use technology to our customers workflow to create custom or easily customizable solutions. Whats more because of its cumulative effect, Syntex solutions grow in power and effectiveness over time, as an investment, it provides compound interest. Syntex product helps companies lower exposure to operational risk, reduce losses and improve quality Syntex is a pioneer and leader in the technology and practice of enterprise and Operational risk management and renowned for helping global companies and industry leaders effectively manage operational performance on a global scale. Our flagship product: Syntex IMPACT Enterprise IMPACT enterprise is a powerful comprehensive Enterprise Risk management (ERM) solutions that helps companies dramatically improve operational excellence IMPACT enterprise:

Facilitates the discovery and removal of exposure to risk that result in organization.

Tracks incidents, investigations and responsibilities, Encourages the creation of remedies, for pro-active and reactive solutions Facilitates assessment of corrective actions Provides site level and enterprise-level views of performance

Today, global industry leaders deploy IMPACT Enterprise worldwide to reduce losses and improve performance. Yet, It is also used in single-site deployments by visionary small-to-medium business in a wide range of industries. Each IMPACT Enterprise user has in common the goal of strategically managing risk while improving software quality It also improves ERM performance by automating regulatory reporting and enabling in-depth analysis of key operational matrices at site and enterprise levels. The IMPACT Enterprise solution integrates seamlessly with your systems-driving new levels of ERM performance that IMPACT the bottom line. Product Highlights Proven: IMPACT enterprise is the pioneering, revolutionary ERM solution that has been deployed and refined since 1995. Worldwide, we currently have more than 600,000 IMPACT Enterprise users Effective: companies that have deployed IMPACT Enterprise report a reduction in incidents that leads to a dramatic ROI. Whats more, the improvement in performance is continual-its like compounded interest for your ROI. Flexible: IMPACT enterprise is designed to work with, not to reinvent, your

workflow. Yet it helps you discover weakness and test refinements to improve your performance. Whats more, it delivers results enterprise-wide, as well as for individual sites. Customizable: IMPACT enterprise can be custom configured by your own team, or by our trained experts. Plus, for smaller organizations, the preconfigured edition incorporates preferred practices that have been proven effective in specific industries. Web based: IMPACT enterprise uses an intuitive web-based interface, making it usable by nearly any member of your workforce with a minimum of training. Multiple languages: IMPACT enterprise supports multiple languages Taps vital information: IMPACT Enterprise encourages workers at every level to contribute information that pertains to reducing exposure to risk and improving safety, productivity and quality. This information immediately becomes visible to any level of management or the workforce that your deployment strategies dictates

IMPACT Enterprise Functionality: Track, Prevent, And Improve

IMPACT enterprise is an integrated system modules, designed to support three basic functions. These functions combine to help reduce an operations exposure to risk and losses while improving quality and productivity. The three functions are track, prevent and improve. A brief summary of each function are explained below:

Track: IMPACT Enterprise improves accountability of enterprise and

operational risk management initiatives through

o Timely data entry o Easy to use tools for responding to issues and recommendations o Automated notification, reminders and approvals o Improved communications of measure and responsibilities across all units and levels of the organization IMPACT enterprise tracks incidents , reactive measures, proactive measures, investigations and recommendations. It provides a view of all tracking to any defined level of access, from upper management to workers on the floor.

Prevent: IMPACT Enterprise helps you to manage your initiative to

closure, and to share lessons learned through state of the art software instead of paper based and verbal systems. IMPACT enterprise tm enables real-time accessibility to: o Investigations o Assessments and audits o Behavioral observations o Meeting and training topics o Corrective actions o Open issues and findings

Improve: IMPACT Enterprise automates data handling, report compilation and distribution. This free you and your team to resolve key operational risk management issues and drive performance improvement. Analysis becomes quick and easy through Discovery on Demand which enables acceleration in

productivity and helps you focus resources in directions that truly affect performance improvement Technical specification for IMPACT Enterprise IMPACT Enterprise has an open, scalable architecture and is designed to seamlessly adapt to your business not the other way around. Current technical features and specification include: Web-enabled 3 tier architecture Oracle or SQL server DBMS platform Runs on Window 2000/ IIS 5.0 / IE 5.5 or better Multi-language support Online help Human resource data interface Email interface via SMTP, MS-Outlook or Lotus Notes File and URL attachment capabilities. Highly configurable workflow User defined fields Customizable fixed format reporting through active reports Graphing/charting through office Web components(Microsoft) or chart FX( software FX)

Risk Management - Useful Tools and Techniques Risk Identification

There are many tools and techniques for Risk identification. Documentation Reviews

* Information gathering techniques o Brainstorming o Delphi technique here a facilitator distributes a questionnaire to experts, responses are summarized (anonymously) & re-circulated among the experts for

comments. This technique is used to achieve a consensus of experts and helps to receive unbiased data, ensuring that no one person will have undue influence on the outcome

o Interviewing
o Root cause analysis for identifying a problem, discovering the causes that led to it and developing preventive action

* Checklist analysis
* Assumption analysis -this technique may reveal an inconsistency of assumptions, or uncover problematic assumptions. * Diagramming techniques o Cause and effect diagrams o System or process flow charts o Influence diagrams graphical representation of situations, showing the casual influences or relationships among variables and outcomes * SWOT analysis * Expert judgment individuals who have experience with similar project in the not too distant past may use their judgment through interviews or risk facilitation workshops

Risk Analysis Tools and Techniques for Qualitative Risk Analysis

* Risk probability and impact assessment investigating the likelihood that each specific risk will occur and the potential effect on a project objective such as schedule, cost, quality or performance (negative effects for threats and positive effects for opportunities), defining it in levels, through interview or meeting with relevant stakeholders and documenting the results. * Probability and impact matrix rating risks for further quantitative analysis using a probability and impact matrix, rating rules should be specified by the organization in advance. See example in appendix B. * Risk categorization in order to determine the areas of the project most exposed to the effects of uncertainty. Grouping risks by common root causes can help us to develop effective risk responses. * Risk urgency assessment - In some qualitative analyses the assessment of risk urgency can be combined with the risk ranking determined from the probability and impact matrix to give a final risk sensitivity rating. Example- a risk requiring a nearterm responses may be considered more urgent to address. * Expert judgment individuals who have experience with similar project in the not too distant past may use their judgment through interviews or risk facilitation workshops.

Tools and Techniques for Quantities Risk Analysis

* Data gathering & representation techniques o InterviewingYou can carry out interviews in order to gather an optimistic (low), pessimistic (high), and most likely scenarios.

o Probability distributions Continuous probability distributions are used extensively in modeling and simulations and represent the uncertainty in values such as tasks durations or cost of project components\ work packages. These distributions may help us perform quantitative analysis. Discrete distributions can be used to represent uncertain events (an outcome of a test or possible scenario in a decision tree) * Quantitative risk analysis & modeling techniques- commonly used for eventoriented as well as project-oriented analysis: o Sensitivity analysis For determining which risks may have the most potential impact on the project. In sensitivity analysis one looks at the effect of varying the inputs of a mathematical model on the output of the model itself. Examining the effect of the uncertainty of each project element to a specific project objective, when all other uncertain elements are held at their baseline values. There may be presented through a tornado diagram. o Expected Monetary Value analysis (EMV) A statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen (generally: opportunities are positive values, risks are negative values). These are commonly used in a decision tree analysis. o Modeling & simulation A project simulation, which uses a model that translates the specific detailed uncertainties of the project into their potential impact on project objectives, usually iterative. Monte Carlo is an example for a iterative simulation. * Cost risk analysis - cost estimates are used as input values, chosen randomly for each iteration (according to probability distributions of these values), total cost will be calculated.

* Schedule risk analysis - duration estimates & network diagrams are used as input values, chosen at random for each iteration (according to probability distributions of these values), completion date will be calculated. One can check the probability of completing the project by a certain date or within a certain cost constraint. * Expert judgment used for identifying potential cost & schedule impacts, evaluate probabilities, interpretation of data, identify weaknesses of the tools, as well as their strengths, defining when is a specific tool more appropriate, considering organizations capabilities & structure, and more.

Risk Response Planning

* Risk reassessment project risk reassessments should be regularly scheduled for reassessment of current risks and closing of risks. Monitoring and controlling Risks may also result in identification of new risks. * Risk audits examining and documenting the effectiveness of risk responses in dealing with identified risks and their root causes, as well as the effectiveness of the risk management process. Project Managers responsibility is to ensure the risk audits are performed at an appropriate frequency, as defined in the risk management plan. The format for the audit and its objectives should be clearly defined before the audit is conducted. * Variance and trend analysis using performance information for comparing planned results to the actual results, in order to control and monitor risk events and to identify trends in the projects execution. Outcomes from this analysis may forecast potential deviation (at completion) from cost and schedule targets.

* Technical performance measurement Comparing technical accomplishments during project execution to the project management plans schedule. It is required that objectives will be defined through quantifiable measures of technical performance, in order to compare actual results against targets. * Reserve analysis compares the amount of remaining contingency reserves (time and cost) to the amount of remaining risks in order to determine if the amount of remaining reserves is enough. * Status meetings Project risk management should be an agenda item at periodic status meetings, as frequent discussion about risk makes it more likely that people will identify risks and opportunities or advice regarding responses.

Risk Management : Experts

Researchers, educators, and experts in Software Risk Management and related topics. * Ask a Professor - Ask A Professor (AAP) is a Department of Defense resource for asking acquisition and logistics questions concerning policies and practices.

* Boehm, Barry - Currently the TRW Professor of Software Engineering, Computer Science Department Director, USC Center for Software Engineering. His current research interests include software process modeling, software requirements engineering, software architectures, software metrics and cost models, software engineering environments, and knowledge-based software engineering. His contributions to the field include the Constructive Cost Model (COCOMO), the Spiral Model of the software process, the Theory W (win-win) approach to software management and requirements determination.

* Charette, Robert N. - Robert N. Charette, Ph.D. is a Cutter Consortium Fellow, Director of the Enterprise Risk Management & Governance practice, and Senior Consultant with the Agile Project Management practice. With almost 30 years of

experience in a wide variety of international technology and management positions, Dr. Charette is recognized as an international authority and pioneer regarding information systems, technology, and telecommunications risk management.

* Ed Conrow - Edmund H. Conrow is the founder and owner of Management and Technology Associates. Dr. Conrow has a proven track record in the application of risk management, project management, and technical skills to moderate to high complexity projects. He has extensive experience on hardware-intensive, softwareintensive, and mixed projects, with life cycle dollar ranges from less than one million dollars to more than 100 billion dollars. Dr. Conrow is the author of the highly regarded book, "Effective Risk Management: Some Keys to Success", Second Edition, American Institute of Aeronautics and Astronautics (AIAA) (2003), author of the project risk management chapter in Harold Kerzner's best selling book, "Project Management: A Systems Approach to Planning, Scheduling, and Controlling", Ninth Edition (2006) and other publications.

* Lister, Tim - Tim Lister is a Fellow of the Cutter Business Technology Council, a member of the Leadership Group of Cutter Consortium's Enterprise Risk Management & Governance practice, and a Senior Consultant with Cutter's BusinessIT Strategies, Agile Software Development & Project Management, Innovation & Enterprise Agility and Sourcing and Vendor Relationships practices. He is also a frequent keynoter at Cutter Summits. Mr. Lister is a principal of the Atlantic Systems Guild, Inc. He is presently involved in assisting organizations with IT risk management and in tailoring methodologies and selecting tools for software development groups to increase project productivity and product reliability. He is also

pursuing work on metrics for making the efforts of software projects more predictable. Mr. Lister has 25 years' professional software development experience. Before the formation of the Atlantic Systems Guild, he worked at Yourdon, Inc. for eight years, where he was an Executive Vice President and Fellow in charge of all instructor/consultants, the technical content of all courses, and the quality of all consultations.

* O'Neill, Don - As an independent consultant, Don ONeill conducts defined programs for managing strategic software improvement. These include directing the National Software Quality Experiment, participating in the National Software Council, and producing and maintaining the section on software inspections in the Software Engineering Institute (SEI) Software Technology Reference Guide.

* Shimel, Brian - Colonel Brian Shimel is Director, Financial Management, Electronic Systems Center (ESC), Hanscom Air Force Base, Massachusetts. As the Centers chief financial officer, Colonel Shimel is responsible for the oversight of more than $4 billion of the Air Forces budget. He provides interpretation, resource allocation and technical guidance to support the ESC strategic goals. Colonel Shimel entered the Air Force in 1984 as an AFROTC Distinguished Graduate, from the University of Vermont. After assignments at Sheppard AFB, TX, Spangdahlem AB, Federal Republic of Germany, and the USAF Academy, CO, He moved, in 1992, to Wright-Patterson AFB, OH, to attend the Air Force Institute of Technology, as a graduate student, where he earned a Masters in Cost Analysis. He served at Los Angeles AFB, CA, Space and Missile Systems Center, HQ Air Force, Washington, D.C., Secretariat of the Air Force for Cost and Econometrics, and at the

AF Cost Analysis Agency as a Senior Weapon Systems Cost Analyst. In 2000, Lt Colonel Shimel was assigned to Cannon AFB, NM, as the 27th Comptroller Squadron Commander. In 2002, Lt Col Shimel was assigned to the Strategic Command and Control System Program Office, Electronic Systems Center, Peterson AFB, CO, as the Chief of Financial Management. In 2004, he was selected to command the 21st Comptroller Squadron, Peterson AFB, CO, serving from June 2004 to July 2005. He reported to the Pentagon in July 2005, as the Military Assistant to the Auditor General of the Air Force where he served until August 2006. He was then assigned to the Air Force Cost Analysis Agency, Washington, D.C., Secretariat of the Air Force for Cost and Econometrics, as Deputy Division Chief, Program Integration, until July 2007 when he assumed his current position.

* Smidts, Carol - A professor at the University of Maryland, Dr. Smidts' research areas focus on dynamic probabilistic risk assessment, human reliability, software reliability, quantitative risk assessment, and software testing.

* Smith, Preston - Dr. Preston has been consulting to and training companies in rapid product development for twenty years. Although Preston may be best known for his many publications, his daily activity centers on onsite consultation and training in new product development using a results-oriented approach that he has honed over the years. Considered an expert in Risk Management and Agile Development. He is coauthor of Developing Products in Half the Time, which has sold over 100,000 copies in several languages. He holds an engineering PhD from Stanford and is a Certified Management Consultant.

* Software Program Manager's Network (SPMN) - The SPMN's mission is to enable managers of large-scale, software-intensive development or maintenance projects to more effectively manage and succeed by identifying and conveying to them best management practices, lessons learned, and directly useful support.

Summary and Conclusion

Risk is commonly defined as a measure of the probability and severity of adverse effects.

Risk management involves managing to achieve an appropriate balance between realizing opportunities for gains and minimizing losses. It is an integral part of good management practise an essential element of good corporate governance Risk management in essence is a process of : Establishing the context Identifying the risks Analysis of the risks Evaluating the risks ( for example considering the likelihood of events and the consequence or impacts of events ) Treating the risks (for example by avoiding the risk, controlling the risk, financing the risk, transferring the risk (e.g. insurance)_ or reducing the risk

through changed work practices) Implement, monitor and review. Communicating with all concerned

APPENDIXES Fig1: Risk Documentation form. ID Risk Description P L E Risk Mitigation Techniques
List each major risk facing the project. Describe each risk in the form conditionconsequence. Example:-Subcontract or staff does not have sufficient technical expertise, so their work is delayed for training and slowed by learning curve

Who

Due

*P

*L *E

For each risk, state one or more approaches to control, avoid, minimize or otherwise mitigate the risk Risk mitigation approaches should yield demonstrable result, so you can measure whether

Assign each risk

State a date by which the

mitigation mitigation on approach is

individual to be implemented

the risk exposure is changing

The risk list could be included as a section in software project plan, or it could remain as a standalone document. Column1:-It is unique identifier for each risk. Column2: -When documenting risk statements, use a condition consequence format. That is, state the risk situation or condition that you are concerned about, followed by at least one potential adverse outcome (consequence) if that risk should turn into problem Column 3: - The P,L,E columns in Fig1 provide locations to capture the probability of a risk materializing into a problem (P), the loss that could be incurred due to risk (L), and the overall risk exposure (P times L) Sort the risk list in descending order of exposure, so the top priority risk items are at the top of the list Used this prioritization mechanism to learn where to focus your risk control energy. Set goals for determining when each risk item has been satisfactorily controlled. For some risk items, your mitigation strategies may focus on reducing the probability, while the approach for other items may emphasize reducing the

impact Column 4:-Risk mitigation approaches allows you to identify the actions you intend to take to keep the risk item under control. Some of your mitigation approaches can be used to address multiple risk factors. For example risks related to failures of the components of the web delivery infrastructure (servers, firewalls, email, and so on) A mitigation strategy that addressed many of those risks was to implement an automated monitoring system that could check the status of the servers and the communication functions periodically and alert us to any failures Other mitigation approaches may include identifying alternatives and options for technical risks, or identifying alternative resource sources for staffing risks. Column 5: - It describes to which person is each risk mitigation assigned Column 6: -State a date by which the mitigation approach is to be implemented.

Fig 2. form for Documenting Individual Risk items

Risk ID: <Sequence number>

Classification: <Risk category, E.g.

Report Date: <date that risk report was last

from SEI taxonomy> updated> Description: <describe each risk jin the form Condition-consequence> Probability: <what is Impact: <what is the Risk Exposure: the likelihood of this risk becoming a problem?> damage if the risk does <Multiply probability become a problem?> times loss to estimate the risk exposure.>

First Indicator: <Describe the earliest indicator or trigger condition that might indicate that the risk is turning into a problem Mitigation Approaches: <State one or more approaches to control, avoid, minimize, or otherwise mitigate the risk. Mitigation approaches may reduce the probability or the impact> Date started: <State Date to Complete: the date the mitigation implementation plan <State the date by which the mitigation Owner: <Assign each risk mitigation action an individual for

was begun

plan is to be

resolution>

implemented> Current status: <Describe the status and effectiveness of the risk mitigation actions as of the date of this report> Contingency Plan: <Describe the actions that will be taken to deal with the situation if this risk factor actually becomes a problem> Trigger for Contingency plan: <state the conditions under which the contingency plan will begin to be implemented

Each mitigation action should be assigned to an individual for implementation and monitoring of the effectiveness It can be helpful to identify a target date for completion of each mitigation approach It can be helpful to identify a target date for completion of each mitigation approach