Managing Risk in Software Project

Plan how to manage the project’s risks: The Risk Management Plan documents how risks will be managed. It is a subset of the project plan and is written before the project begins.
Identify risks: One simple approach is to get representatives of all the affected groups in a room and have a workshop. Circulate a provisional list to excite attention. Get their ideas down onto large sheets of paper you can blu-tack to the walls. Circulate a revised list after the meeting.

Repeat the process half-way through the project, and identify how many have not occurred, and how many unforeseen ones had occurred.

Risk Alerts are the triggers used to identify when a risk is imminent. Typical test-related triggers are:

1. Reduction in the number of lines of code per bug found.
2. Finding an unacceptably-high number of priority-1 and -2 bugs in a build.
3. Finding an unacceptably-high number of bugs in a component.
4. Late arrival of signed-off specifications for use as a baseline.
5. Failure of performance tests to achieve targets.
6. Growing code complexity.
7. Growing code turmoil.

Monitoring such risks is easier when an alerting system is in place. The existence of a risk log allows the test team to identify priorities and provides a good basis for deciding the mix of tests to be planned.

Risks can be grouped by sources and by kinds and a risk kind is for example that something doesn’t work, that it works too late, too slowly, at the wrong time, or that it has unintended side-effects. These groups are sensitive to risk drivers in that a driver can change a whole group of risks.

The failure of the project to use an appropriate development method was having a knock-on effect throughout the whole of the project. It was a source of risks and a major driver. Here are some more are

1. Use of an inappropriate (unrelated to the risk) method or process.
2. Lack of customer involvement:Apart from the obvious need for a sufficient set of requirements
3. There is the need for feedback to users of (fragments of) the proposed solution.
4. Dissimilarity to previous projects: If “we’ve never done anything as (big/complex/different) as this before” is an issue, then beware.
5. Project complexity: This is relative to the experience of an organization. What might exhaust some organizations will be run-of-the-mill to others.
6. • Requirements volatility:If such changes aren’t allowed for, the project will soon deteriorate.(56)

Related :

How do we test a software ?
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT