SOFTWARE ENGINEERING TECHNIQUES

LESSON 3:

Topics Covered develop software, how we support a growing volume of

Software Crisis, Risk analysis and Management, Risk existing software, and how we can expect to keep pace with a
Identification, Risk Monitoring, Risk Management and growing demand for more software.
Contingency Planning Now we’ll have a look onto what you mean by risk analysis and
Objectives management
Upon completion of this Lesson, you should be able to: Risk Analysis and Management
• Know what do you mean by software crisis Risk analysis and management are a series of steps that help a
• Explain what is meant by a risk in software software team to understand and manage uncertainty. What is
risk?
• Know more about the risk management activities
A risk is a potential problem, it might happen, it might not.
• Explain how to identify a risk
But, regardless of the out come, it is a good idea to identify it,
• Know what is contingency planning assess its probability of occurrence, estimate its impact, and
In the previous session we learnt about software testing and establish a contingency plan should the problem actually occur.
software quality. In this session we learn about software crisis Let us see the different types of risks
and risk analysis. Ever taken a risk in life! Never take a chance
What do you mean by project risks?
here! Analyze all the risks involved. Or you may loose your
money. Project Risks
threaten the project plan. That is, if project risks become real, it
Software Crisis
is likely that project schedule will slip and that costs will increase.
Many industry observers have characterized the problems
Project risks identify potential budgetary, schedule, personnel
associated with the software development as a “crisis”. Yet, the
staffing and organization, resource, customer, and requirements
great successes achieved by the software industry have led many
problems and their impact on a software project.
to question whether the term software crisis is still appropriate.
What do you understand by the technical risks?
It is true that the software people succeed more often than they
fail. It is also true that the software crisis predicted 30 years ago Technical Risks
never seemed to materialize. What we really have may be threaten the quality and timeliness of the software to be
something rather different. produced. If a technical risk becomes a reality, implementation
The word crisis is defined in the Webster’s dictionary as “a may become difficult or impossible. Technical risks identify
turning point in the course of anything; decisive or crucial time, potential design, implementation, interface, verification, and
stage or event.” Yet in terms of overall software quality and the maintenance problems. In addition, specification ambiguity,
speed with which computer-based systems and products are technical uncertainty, technical uncertainty, technical obsolescence,
developed, there has been no “turning point,” no “decisive and “leading-edge” technology are also risk factors. Technical
time,” only slow, evolutionary change, punctuated by explosive factors occur because the problem is harder to solve than we
technological changes in disciplines associated with software. thought it would be.
The word “crisis” has yet another definition: “ the turning What is a business risk? And what are the candidates for the
point in the course of a disease, when it becomes clear whether top five business risks?
the patient will live or die.” This definition may give us a clue Business Risks
about the real nature of the problems that have plagued threaten the viability of the software to be built. Candidates for
software development. the top five business risks are:
What we really have might be better characterized as a chronic i. Think that you have built an excellent product or system that
affliction. The word affliction is defined as “anything causing no one really wants-What a waste of energy and time!!- This
pain or distress.” But the definition of the adjective chronic is is what you call as market risk
the key to our argument: “lasting a long time or recurring often; ii. Or think of building a product that no longer fits into the
continuing indefinitely.” It is far more accurate to describe the overall business strategy for the company. This is strategic
problems we have endured in the software business as a chronic risk
affliction than a crisis.
iii. Or think of building a product that the sales force does not
Regardless of what we call it, the set of problems that are understand how to sell, or maybe after you build the
encountered in the development of computer software is not product, you lose the support of senior management due to
limited to software that “doesn’t function properly.” Rather, the a change in focus or change in management. This is
affliction encompasses problems associated with how we management risk.

© Copy Right: Rai University

8 3E.253
iv. Or your project loses budgetary or personnel commitment. c. Critical-failure to meet requirements would degrade the

SOFTWARE ENGINEERING TECHNIQUES

This is budget risk. system performance to a point where mission success is
Another way of categorizing risks has been proposed by questionable; expected value of costs $100K to $500K.
Charette. d. Catastrophic-failure to meet the requirement would result
in mission failure; Expected loss in excess of $500K.
Known Risks
These are the ones that can be uncovered after careful evaluation The degree of impact and the risk components are then plotted
of the project plan, the business and technical environment in on a grid to understand the gravity of each type of risk.
which the project is being developed, and other reliable All of us talk about risk in our daily life as well in software, but
information sources. have you ever thought of an effective strategy of dealing with
Predictable Risks are extrapolated from past experience [e.g. risks in software
staff turnover, poor communication with the customer, An effective strategy for dealing with risk must consider three
dilution of staff effort as ongoing maintenance requests are issues.
serviced]. • Risk Avoidance
Unpredictable Risks are the spoilsports-they can and do occur, • Risk Monitoring
but they are extremely difficult to identify in advance.
• Risk Management and Contingency Planning.
Now let us see what is meant by risk identification?
If a Software team adopts a proactive approach to risk,
Risk Identification avoidance is always the best strategy. This is achieved by
is a systematic attempt to specify threats to the project plan. By developing a plan for Risk Mitigation. E.g.: Let us assume
identifying known and predictable risks, the project manager that high staff turnover is a project risk, Mitigation would
takes a first step towards avoiding them when possible and require steps to reduce turnover, such as:
controlling them when necessary. • Meet with current staff to determine causes for turnover
A Risk Item Checklist • Mitigate controllable causes before project commences
can be created on the basis of a subset of risks such as risks
• Assume turnover will occur and develop techniques to
associated with:
ensure continuity when people leave
• Product size
• Conduct peer reviews of all work
• Business impact
• Assign a backup staff member for every critical technologist
• Customer characteristics
With out monitoring the risk we cannot avoid it. It is like our
• Process definition old saying “Look before you leap”
• Development environment
Risk Monitoring
• Technology to be built
• General attitude of team members based on project pressure
• Staff size and experience
• Degree to which team has jelled
Here is yet another classification of risks!! • Interpersonal relationship among team members
The U.S Air force has written an excellent pamphlet containing • Potential problems with compensation and benefits
guidelines for software risk identification and abatement. The
• Availability of job within the company and outside it.
risk COMPONENTS as defined as:
a. Performance Risk-the degree of uncertainty that the Risk Management and Contingency Planning
product will meet its requirements and be fit for its intended assume that mitigation efforts have failed and that the risk has
use. become a reality. If project is already underway and a number of
people announce that they will be leaving, and if the mitigation
b. Cost Risk-the degree of uncertainty that the project budget
strategy has been followed, backup is available, information is
will be maintained.
documented, and knowledge has been dispersed across the
c. Support Risk-the degree of uncertainty that the resultant team, In addition, the project manager may refocus resources to
software will be easy to correct, adapt and enhance. enable the team to “get up to speed” It is important to note
d. Schedule Risk-the degree of uncertainty that the project that Risk Mitigation, Monitoring And Management
schedule will be maintained and that the product will be [RMMM] steps incur additional project cost. For a large project,
delivered on time. 30 to 40 risks may be identified. If between 3 and 7 risk
The impact of each risk driver on the risk component is divided management steps are identified for each, risk management may
into one of four impact categories. become a project in itself. We can adapt the Pareto principle.
80% of the overall project risk can be accounted for by only 20%
a. Negligible-failure to meet requirements would create
of the identified risks. It would therefore be necessary to
inconvenience; expected value of impact less than S1K.
concentrate on the 20% of the critical causes and avoid, mitigate
b. Marginal-failure to meet requirements would result in or manage them.
degradation of secondary mission; expected value of impact
$1K to $100K

© Copy Right: Rai University

3E.253 9
 Risk analysis can absorb a significant amount of project Notes
SOFTWARE ENGINEERING TECHNIQUES

planning effort. But the effort is worth it. “If you know the
enemy and know yourself, you need not fear the result of a
hundred battles.” For the software project manager, the enemy
is risk.
PPT-1
Implicit Risk Management
• Having a good software process is the first step in Risk
Management
• Perhaps the principal task of a manager is to minimise
risk
• The ‘risk’ inherent in an activity is a measure of the
uncertainty of the outcome of that activity
• High-risk activities cause schedule and cost overruns
• Risk is related to the amount and quality of available
information. The less information, the higher the risk
PPT-2
Top Ten Software Risks
1. Personnel Shortfalls
2. Unrealistic Schedules and Budgets
3. Developing the Wrong Software Functions
4. Developing the wrong user interface
5. Gold plating
6. Continuing stream of requirements changes
7. Shortfalls in Externally Furnished components
8. Shortfalls in Externally performed tasks
9. Real-time performance shortfalls
10. Straining Computer Science Capabilities
Exercises
1. As software becomes more pervasive, risks to the public
(due to the faulty programs) become an increasingly
significant concern. Develop a realistic doomsday scenario
(other than Y2K) where the failure of a computer program
could do great harm(either economic or human).
Further Readings and Information Resources
The current state of the art in software engineering can best be
determined from monthly publications such as IEEE Software,
Computers and the IEEE Transactions on Software
Engineering.
Minasi(The software Conspiracy: Why Software Companies Put
Out Faulty Products, How They Can Hurt You, and What You
Can Do, McGraw Hill, 2000) argues that the modern scourge of
software bugs can be eliminated and suggests ways to
accomplish this.
A wide variety of information sources on software related
topics and management is available on the Internet. An up-to-
date list of World Wide Web references that are relevant to
software can be found at the SEPA Web site:
http://www.mhhe.com/engcs/compsci/pressman/resources/
product.mhtml

© Copy Right: Rai University

10 3E.253