SOFTWARE ENGINEERING LECTURE III & IV

1. 1
Risk Management

2. 2
Risk Management
Objectives
– To explain the concept of risk & to develop its role
within the software development process
– To introduce the use of risk management as a
means of identifying & controlling risk in software
development

3. 4
Definitions of risk
• “The possibility of suffering harm or loss; danger”
• “The possibility of loss or injury”
• “Chance of danger, injury, loss”
• “A measure of the probability & severity
of adverse effects”
Probability/
uncertainty
Something bad
happening

4. 5
Risks in the everyday world
• Financial risks - “your house is at risk if you fail to
repay your mortgage or any loans secured on it”
• Health risks - “the chance that a person will
encounter a specified adverse health outcome (like
die or become disabled)”
• Environmental & ecological risks - “the likelihood
of extinction due to exposure of terrestrial wildlife to
contaminants”
• Security risks - “there is a significant risk that
widespread insertion of government-access key
recovery systems into the information infrastructure
will exacerbate, not alleviate, the potential for crime
and information terrorism”
More examples?
X

5. 6
How is risk dealt with?
• Basic process: identify the risk -> analyse its
implications -> determine treatment methods ->
monitor performance of treatment methods
• Techniques & heuristics for the identification,
analysis, treatment & monitoring of risk
• Risk management is a project management tool to
assess & mitigate events that might adversely impact
a project, thereby increasing the likelihood of success
Insurance companies depend on understanding risk

6. 7
Why is the software world interested in risk?
• Many post-mortems of software project disasters
indicate that problems would have been avoided (or
strongly reduced) if there had been an explicit early
concern with identifying & resolving high-risk
elements!
• An obvious cost factor!
Successful project managers are good risk managers!

7. Sources of software risk (systems context)
Technology
Cost
Software
Schedule
Hardware
People
SYSTEM

8. 9
Why is it often forgotten?
• Optimistic enthusiasm at the start of projects
• Software process can lead to over-commitment &
binding requirements much too early on
• Premature coding
• The “add-on” syndrome
• Warning signals are missed
• Legal implications
• Poor software risk management by project managers

9. 10
Software risk management
• Objectives
– To identify, address & eliminate risk items before
they become either threats to successful software
operation or major sources of software rework
– Necessary that some form of measurement is
undertaken to determine & classify the range of
risks a software development project faces, & to
identify areas where a significant exposure exists
• The discipline attempts to provide a set of principles &
practices to achieve the above
• A response to change & uncertainty

10. 11
The need to manage risk
Risk
Expert knowledge,
judgement & experience
Individual knowledge,
judgement & experience
System complexity
Methods, tools &
processes
Reproduced from [Higuera 1996]

11. 12
The questions
What can go wrong?
What is the likelihood
it will go wrong?
What are the consequences?
What can be done?
What options are available?

12. Software risk management steps & techniques
Risk management
Risk assessment
Riskcontrol
Risk identification
Riskanalysis
Riskprioritisation
Checklists
Decision-driver analysis
Assumption analysis
Decomposition
Risk exposure
Riskleverage
Compound-riskreduction
Performance models
Cost models
Networkanalysis
Decision analysis
Quality-factoranalysis
Buying information
Risk avoidance
Risktransfer
Riskreduction
Risk-elementplanning
Risk-planintegration
Prototypes
Simulations
Benchmarks
Analyses
Staffing Milestonetracking
Top10tracking
Risk reassessment
Corrective action
13
Risk-management planning
Riskresolution
Risk monitoring
[Boehm 1991]

13. 14
Risk assessment
• Risk identification - listing project-specific
risk items that are likely to compromise a
project’s success
• Risk analysis - assessing the loss
probability & loss magnitude for each
identified risk item, & assessing compound
risks
• Risk prioritisation - ordering & ranking the
risk items identified & analysed

14. UNIT-IV
Graphics:-Creating Graphs, The
Workhorse of R Base Graphics, the
plot() Function – Customizing
Graphs, Saving Graphs to Files

15. Creating Graphs :- R is profoundly used for its substantial
techniques for graphical interpretation of data of utmost
importance of analysts. The primary styles are: dot plot,
density plot (can be classified as histograms and kernel), line
graphs, bar graphs (stacked, grouped and simple), pie charts
(3D,simple and expounded), line graphs(3D,simple and
expounded), box-plots(simple, notched and violin plots), bag-
plots and scatter-plots (simple with fit lines, scatter-plot
matrices, high-density plots and 3-D plots).
The foundational function for creating graphs: plot(). This
includes how to build a graph, from adding lines and points to
attaching a legend.

16. The Workhorse of R Base Graphics: The plot() Function The plot() function forms
the foundation for much of R’s base graphing operations, serving as the vehicle
for producing many different kinds of graphs. plot() is a generic function, or a
placeholder for a family of functions. The function that is actually called depends
on the class of the object on which it is called. The basic syntax to create a line
chart in R is −
plot(v, type, col, xlab, ylab)
Following is the description of the parameters used −
• v is a vector containing the numeric values.
• type takes the value "p" to draw only the points, "l" to draw only the lines
and "o" to
draw both points and lines.
• xlab is the label for x axis.
• ylab is the label for y axis.
• main is the Title of the chart.
• col is used to give colors to both the points and lines.

17. Examples of plot function
# Define the cars vector with 5 values
cars <- c(1, 3, 6, 4, 9)
# Graph the cars vector with all defaults
plot(cars)
The default argument of type is points
# Define the cars vector with 5 values
cars <- c(1, 3, 6, 4, 9)
# Graph cars using blue points with lines
plot(cars, type="o", col="blue")
# Create a title with a red, bold/italic font
title(main="Autos",col.main="red", font.main=4)
# Create the data for the chart.
v <- c(7,12,28,3,41)
# Give the chart file a name.
png(file = "line_chart.jpg")
# Plot the bar chart.
plot(v,type = "o")
# Save the file.
dev.off()

18. call plot() fucntion with an X vector and a Y vector, which are
interpreted as a set of pairs in the (x,y) plane.
plot(c(1,2,3), c(1,2,4))
This will cause a window to pop up, plotting the points (1,1), (2,2),
and (3,4), this is a very plain-Jane graph.
plot(
plot(c(-3,3), c(-1,5), type = "n", xlab="x", ylab="y")
#This draws axes labeled x and y. The horizontal (x) axis ranges
from
−3 to 3. The vertical (y) axis ranges from −1 to 5. The argument
type="n" means that there is nothing in the graph itself.

19. Overlaying Plots:- If the plot( ) function is called many times, the current graph will be
plotted in the same window and the previously existed graph will be replaced by
the same. But in order to have a comparision between the results this plot is
used. It is done by using the lines( ) and points( ) functions which add lines and points to the
respective existing plot.
x <- seq(-pi,pi,0.1)
plot(x,sin(x),main="overlaying Graphs",type="l",col="blue")
lines(x,cos(x),col="red")
legend('topleft',c("sin(x)","cos(x)"),fill=c("blue","red"))

20. Abline function:- This function simply draws a straight line,with the function’s
arguments treated as the intercept and slope of the line.
x <- c(1,2,3)
y <- c(1,3,8)
plot(x,y,col=”red”,pch=”+”)
lmout <- lm(y ~ x)
abline(lmout)
After the call to plot(), the graph will simply show
the three points, along with the x- and y- axes with
hash marks. The call to abline() then adds a line to
the current graph. Now, which line is this?
As the result of the call to the linear-regression
function lm( ) is a class instance containing the
slope and intercept of the fitted line, as well as
various other quantities that don’t concern us
here. We’ve assigned that class instance to lmout.
The slope and intercept will now be in
lmout$coefficients.

21. Some of the coloring functions in Graphs.
FUNCTION USAGE EXAMPLE
colors( ) Returns the built-in color
names which R knows about.
> col <- colors() [234]
> col
[1] "gray81"
rgb( ) This function creates colors
corresponding to the given
intensities (between 0
and max) of the red, green and
blue primaries. It returns hex
code of the color
> rgb(1,0,1)
[1] "#FF00FF"
> rgb(33,64,123,max=255)
[1] "#21407B"
> rgb(0.3,0.7,0.5)
[1] "#4CB280"
cm.colors( ) > Create a vector
of n contiguous colors.
cm.colors(1)
[1] "#80FFFFFF“
rainbow( ) Create a vector
of n contiguous colors.
> rainbow(3)
[1] "#FF0000FF"
"#00FF00FF" "#0000FFFF"

22. heat.colors( ) Create a vector
of n contiguous colors.
> heat.colors(1)
[1] "#FF0000FF"
terrain.colors( ) Create a vector
of n contiguous colors.
> terrain.colors(2)
[1] "#00A600FF"
"#F2F2F2FF"
par( ) par can be used to set or
query
graphical parameters.
Parameters can be set by
specifying them as
arguments
to par in tag = value form,
or
by passing them as a list of
tagged values.
>par(mfrow=c(1,2))
# set the plotting
area into a 1*2 array
so 2 plots can
be used
https://www.youtub
e.com/watch?v=Z3V
4Pbxeahg

23. 1
2
Software Quality
 In 2005, ComputerWorld [Hil05] lamented that
 “bad software plagues nearly every organization that uses
computers, causing lost work hours during computer downtime,
lost or corrupted data, missed sales opportunities, high IT support
and maintenance costs, and low customer satisfaction.
 A year later, InfoWorld [Fos06] wrote about the
 “the sorry state of software quality” reporting that the quality
problem had not gotten any better.
 Today, software quality remains an issue, but who is to blame?
 Customers blame developers, arguing that sloppy practices lead
to low-quality software.
 Developers blame customers (and other stakeholders), arguing
that irrational delivery dates and a continuing stream of changes
force them to deliver software before it has been fully validated.

24. 3
Quality
 The American Heritage Dictionary defines
quality as
 “a characteristic or attribute of something.”
 For software, two kinds of quality may be
encountered:
 Quality of design encompasses requirements,
specifications, and the design of the system.
 Quality of conformance is an issue focusedprimarily
on implementation.
 User satisfaction= compliant product + good quality
+ delivery within budget and schedule
4
Software Quality
 Software quality can be defined as:
 An effectivesoftware process applied in a manner
that creates a useful product that provides
measurable value for those who produce it and those
who use it.
 This definition has been adapted from [Bes04] and
replaces a more manufacturing-oriented view
presented in earlier editions of this book.

25. 5
Effective Software Process
 An effective software process establishes the
infrastructure that supports any effort at building a high
quality software product.
 The management aspects of process create thechecks
and balances that help avoid project chaos—akey
contributor to poor quality.
 Software engineering practices allow the developer to
analyze the problem and design a solid solution—both
critical to building high quality software.
 Finally, umbrella activities such as changemanagement
and technical reviews have as much to do with quality as
any other part of software engineering practice.
6
Useful Product
 A useful product delivers the content, functions,
and features that the end-user desires
 But as important, it delivers these assets in a
reliable, error free way.
 A useful product always satisfies those
requirements that have been explicitly stated
by stakeholders.
 In addition, it satisfies a set of implicit
requirements (e.g., ease of use) that are
expected of all high quality software.

26. Adding Value
 By adding value for both the producer and user of a
software product, high quality software provides benefits
for the software organizationand the end-user
community.
 The software organization gains added value because
high quality software requires less maintenance effort,
fewer bug fixes, and reducedcustomer support.
 The user community gains added value because the
application provides a useful capability in a way that
expedites some business process.
 The end result is:
 (1) greater software product revenue,
 (2) better profitability when an application supports a
business process, and/or
 (3) improved availability of information that is crucial for the
The Software Quality Dilemma
 If you produce a software system that has terrible
quality, you lose becauseno one will want to buy it.
 If on the other hand you spend infinite time, extremely
large effort, and huge sums of money to build the
absolutelyperfect piece of software, thenit's going to
take so long to complete and it will be so expensive to
produce that you'll be out of business anyway.
 Either you missed the market window, or you simply
exhaustedall your resources.
 So people in industry try to get to that magical middle
ground where the product is good enoughnot to be
rejectedright away, such as during evaluation, but also
not the object of so much perfectionismand so much
work that it would take too long or cost too much to
complete. [Ven03]
. 8

27. “Good Enough” Software
 Good enough software delivers high quality functions and
features that end-users desire, but at the same time it delivers
other more obscure or specialized functions and features that
contain known bugs.
 Arguments against “good enough.”
 It is true that “good enough” may work in some application
domains and for a few major software companies. After all, if a
company has a large marketing budget and can convince enough
people to buy version 1.0, it has succeeded in locking them in.
 If you work for a small company be wary of this philosophy. If you
deliver a “good enough” (buggy) product, you risk permanent
damage to your company’s reputation.
 You may never get a chance to deliver version 2.0 because bad
buzz may cause your sales to plummet and your company to fold.
 If you work in certain application domains (e.g., real time
embedded software, application software that is integrated with
hardware can be negligent and open your company to expensive
litigation.
9
10
Cost of Quality
 Prevention costs include
 quality planning
 formal technical reviews
 test equipment
 Training
 Internal failure costs include
 rework
 repair
 failure mode analysis
 External failure costs are
 complaint resolution
 product return and replacement
 help line support
 warranty work

28. 11
Cost
 The relative costs to find and repair an error or defect
increase dramatically as we go from prevention to
detection to internal failure to external failure costs.
12
Quality and Risk
 “People bet their jobs, their comforts, their safety, their
entertainment, their decisions, and their very lives on
computer software. It better be right.” SEPA, Chapter 1
 Example:
 Throughout the month of November, 2000 at a hospital in
Panama, 28 patients received massive overdoses of
gamma rays during treatment for a variety of cancers. In
the months that followed, five of these patients died from
radiation poisoning and 15 others developed serious
complications. What caused this tragedy? A software
package, developed by a U.S. company, was modified by
hospital technicians to compute modified doses of radiation
for each patient.

29. Negligence and Liability
 The story is all too common. A governmental or
corporateentity hires a major software developer or
consultingcompany to analyze requirements and then
design and construct a software-based“system” to
support some major activity.
 The system might support a major corporate function (e.g.,
pension management) or some governmental function
(e.g., healthcare administration or homeland security).
 Work begins with the best of intentions on both sides,
but by the time the system is delivered, things have gone
bad.
 The system is late, fails to deliver desired features and
functions, is error-prone, and does not meet with
customer approval.
 Litigationensues.
13
Quality and Security
 Gary McGrawcomments [Wil05]:
 “Software security relates entirely and completely to
quality. You must think about security, reliability,
availability, dependability—at the beginning, in the
design, architecture, test, and coding phases, all through
the software life cycle [process]. Even people aware of
the software security problem have focused on late life-
cycle stuff. The earlier you find the software problem, the
better. And there are two kinds of software problems.
One is bugs, which are implementation problems. The
other is software flaws—architectural problems in the
design. People pay too much attention to bugs and not
enoughon flaws.”
14