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: Submitted by:

Mrs Manisha Kaushik Abhijit KumarLecturer 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 system’s 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 today’s 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 won’t 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 haven’t 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 Proposed New Agenda

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.

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

The wrong risk management techniques were being used:    Simple techniques (checklists,

scoring tables, complex calculation tools) deployed in 1990’s 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 cost-effective.

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

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.

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

Risk management was too standard:    Many risk management

approaches/tools aimed to

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

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.

solutions.

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 didn’t understand them, they didn’t have confidence in them and could not communicate the results well.

Risk management methods must emphasize communication and understandability of results

Researchers were too theoretical and consultants too naïve:    Researchers ignored practical

implications or constraints.  Lack of interdisciplinary research (risk management methods not leveraged from psychologists, economists, civil engineers, etc.).  Consultants have used/reused the same old simple methods without true concern about their serious limitations.

Researchers need to provide more practice results. Consultants need to upgrade their knowledge and gain a deeper understanding of methods/tools.

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

 

Risk Example

A company has introduced object–oriented (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

Kloman’s 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. A continual state of project instability

ii. Constant fire fighting.

iii. Multiple schedule slippages because of reducing surprise factors

iv. 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. Risk prevention

ii. Risk mitigation and correction

iii. 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. It’s what we don’t know that can hurt us

Uncertainty is a normal and unavoidable characteristic of most software

pretend are under control. It’s what we don’t 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 .That’s 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 software–dependent 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

environment also contributes to un-certainty. [3] 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 Risk factor % of Project at

Risk

MIS Creeping user requirement 80%

Excessive schedule pressure 65%

Low quality 60%

Cost overruns 55%

Inadequate Config. control 50%

Commercial Inadequate user documentation 70%

Low user satisfaction 55%

Excessive time to market 50%

Harmful Competitive actions 45%

Litigation expense 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 don’t 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 don’t 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 trade-

offs 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

entity’s 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(don’t 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: don’t 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 can’t afford or don’t 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 project’s 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 can’t 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 company’s 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 organization’s

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 organization-

including 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 don’t 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- don’t 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 world’s 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 customer’s 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

standardization’s management system standards, and the American Chemistry

Council’s Responsible Care management system elements. It also facilitates the

certification process of programs such as Occupational Safety and Health

Administrator’s 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 customer’s

workflow to create custom or easily customizable solutions. What’s 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. What’s 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. What’s 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 operation’s 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 near-

term 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 Interviewing–You 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 event-

oriented 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

organization’s 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 Manager’s 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 project’s 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 plan’s 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, software-

intensive, 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 Business-

IT 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 O’Neill 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

Center’s chief financial officer, Colonel Shimel is responsible for the oversight of

more than $4 billion of the Air Force’s 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

Who Due

List each major risk *P *L *E For each risk, state Assign State a date

facing the project.

Describe each risk in

the form “condition-

consequence”.

Example:-“Subcontract

or staff does not have

sufficient technical

expertise, so their work

is delayed for training

and slowed by learning

curve”

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

the risk exposure is

changing

each risk

mitigation

on

individual

by which the

mitigation

approach is

to be

implemented

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.

from SEI taxonomy>

Report Date: <date

that risk report was last

updated>

Description: <describe each risk jin the form “Condition-consequence”>

Probability: <what is

the likelihood of this

risk becoming a

Impact: <what is the

damage if the risk does

become a problem?>

Risk Exposure:

<Multiply probability

times loss to estimate

problem?> 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

the date the mitigation

implementation plan

was begun

Date to Complete:

<State the date by

which the mitigation

plan is to be

implemented>

Owner: <Assign each

risk mitigation action

an individual for

resolution>

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