Software Engineering 2

UNIT-V
Risk Management: Reactive vs Proactive Risk Strategies, software risks, Risk
Identification, Risk Projection, Risk Refinement, RMMM, RMMM Plan.

Quality Management: Quality Concepts, Software Quality assurance, Software

Reviews, Formal Technical Reviews, Statistical Software Quality assurance,
Software Reliability, The ISO 9000 Quality standards.

Risk is an undesired event or circumstance that occur while a project is underway

It is necessary for the project manager to anticipate and identify different risks
that a project may be susceptible to.

Risk Management aims at reducing the impact of all kinds of risk that may
affect a project by identifying, analyzing and managing them

Reactive Vs. Proactive test strategies

 Reactive Risks:

 Project team reacts to risks when they occur.

 The team flies into action in an attempt to correct the problem rapidly.
This is often called a fire fighting mode.

 When this fails, ―crisis management‖ takes over and the project is in
real jeopardy.

 Proactive Risks

 Potential risks are identified, their probability and impact are assessed,
and they are ranked by importance.

 The software team establishes a plan for managing risk.

 The primary objective is to avoid risk, but because not all risks can be
avoided, the team works to develop a contingency plan that will enable
it to respond in a controlled and effective manner.

Software Risks

Characteristics

Risk always involves two characteristics

 Uncertainty the risk may or may not happen;

Dept of Computer Science & Engineering

Software Engineering 3

 Loss if the risk becomes a reality, unwanted consequences or losses will

occur.

When risks are analyzed, it is important to quantify the level of

uncertainty and the degree of loss associated with each risk

Types of Risks

 Project risk: Threaten the project plan and affect schedule and resultant cost

 Technical risk: Threaten the quality and timeliness of software to be

produced

 Business risk: Threaten the viability of software to be built

 Known risk: These risks can be recovered from careful evaluation

 Predictable risk: Risks are identified by past project experience

 Unpredictable risk: Risks that occur and may be difficult to identify

Risks Identification

 Risk identification is a systematic attempt to specify threats to the project

plan.

By identifying known and predictable risks, the project manager takes

a first step toward avoiding them when possible and controlling them when
necessary.

 Two distinct types of risks for each category of risks specified above

 Generic risks are a potential threat to every software project.

 Product-specific risks can be identified only by those with a clear

understanding of the technology, the people, and the environment that
is specific to the project at hand.

One method for identifying risks is to create a risk item checklist.

The checklist can be used for risk identification

 Product size

 Business impact .

 Customer characteristics

Dept of Computer Science & Engineering

Software Engineering 4

 Process definition

 Development environment

 Technology to be built

 Staff size and experience

Assessing Overall Project Risk:

The following questions have been derived from risk data obtained by
surveying experienced software project managers in different parts of the world. The
questions are ordered by their relative importance to the success of a project.

 Have top software and customer managers formally committed to

support the project?

 Are end-users enthusiastically committed to the project and the

system/product to be built?

 Are requirements fully understood by the software engineering team

and their customers?

 Have customers been involved fully in the definition of requirements?

 Do end-users have realistic expectations?

 Is project scope stable?

 Does the software engineering team have the right mix of skills?

 Are project requirements stable?

 Does the project team have experience with the technology to be

implemented?

 Is the number of people on the project team adequate to do the job?

 Do all customer/user constituencies agree on the importance of the

project and on the requirements for the system/product to be built?

 Is project scope stable?

 Does the software engineering team have the right mix of skills?

 Are project requirements stable?

Dept of Computer Science & Engineering

Software Engineering 5

 Does the project team have experience with the technology to be

implemented?

 Is the number of people on the project team adequate to do the job?

 Do all customer/user constituencies agree on the importance of the

project and on the requirements for the system/product to be built?

The degree to which the project is at risk is directly proportional to the

number of negative responses to these questions.

Risk Components and Drivers:

 The U.S. Air Force has written a pamphlet that contains excellent guidelines
for software risk identification and abatement.

 The Air Force approach requires that project manager identify the risk drivers
that affect software risk components.

 The risk components are defined in the following manner.

 Performance risk - the degree of uncertainty that the product will meet
its requirements and be fit for its intended use.

 Cost risk - the degree of uncertainty that the project budget will be
maintained.

 Support risk - the degree of uncertainty that the resultant software will
be easy to correct, adapt, and enhance.

 Schedule risk - the degree of uncertainty that the project schedule will
be maintained and that the product will be delivered on time.

The impact of each risk driver on the risk component is divided into one
of four impact categories—negligible, marginal, critical, or catastrophic.

Dept of Computer Science & Engineering

Software Engineering 6

Impact Assessment

Risks Projection:

Risk Estimation

 It estimates the impact of risk on the project and the product

 It attempts to rate each risk in two ways

 the likelihood or probability that the risk is real

 the consequences of the problems associated with the risk, should it

occur.

 The project planner, along with other managers and technical staff, performs
four risk projection steps:

 establish a scale that reflects the perceived likelihood of a risk.

 delineate the consequences of the risk.

 estimate the impact of the risk on the project and the product.

Dept of Computer Science & Engineering

Software Engineering 7

 note the overall accuracy of the risk projection so that there will be no
misunderstandings.

 The intent of these steps is to consider risks in a manner that leads to

prioritization.

 No software team has the resources to address every possible risk with the
same degree of rigor.

 By prioritizing risks, you can allocate resources where they will have the most
impact.

Developing a Risk Table:

 A risk table provides a project manager with a simple technique for risk
projection

 Once the first four columns of the risk table have been completed, the table is
sorted by probability and by impact.

High-probability, high-impact risks percolate to the top of the table,

and low-probability risks drop to the bottom. This accomplishes first-order risk
prioritization.

 The project manager studies the resultant sorted table and defines a cutoff
line.

Dept of Computer Science & Engineering

Software Engineering 8

The cutoff line (drawn horizontally at some point in the table) implies
that only risks that lie above the line will be given further attention. Risks that fall
below the line are re-evaluated to accomplish second-order prioritization.

 The column labeled RMMM contains a pointer into a Risk Mitigation,

Monitoring and Management Plan or alternatively, a collection of risk
information sheets developed for all risks that lie above the cutoff.

Assessing Risk Impact:

 The overall risk exposure, RE, is determined using the following relationship

RE = P x C

P is the probability of occurrence for a risk, and

C is the cost to the project should the risk occur

 For example, assume that the software team defines a project risk in the
following manner:

Risk identification.

Only 70 percent of the software components scheduled for reuse will, in fact,
be integrated into the application. The remaining functionality will have to be
custom developed.

Risk probability. 80% (likely).

Risk impact.

Dept of Computer Science & Engineering

Software Engineering 9

60 reusable software components were planned. If only 70 percent can be

used, 18 components would have to be developed from scratch (in addition to
other custom software that has been scheduled for development). Since the
average component is 100 LOC and local data indicate that the software
engineering cost for each LOC is $14.00, The overall cost (impact) to develop
the components would be 18 x 100 x 14 = $25,200.

Risk exposure. RE = 0.80 x 25,200 ~=$20,200.

Risks Refinement:

 One way to do this is to represent the risk in

condition-transition-consequence (CTC).

i.e., the risk is stated in the following form:

Given that <condition> then there is concern that (possibly) <consequence>.

Risk Mitigation Monitoring and Management(RMMM)

 An effective strategy must consider three issues:

 Risk avoidance,

 Risk monitoring, and

 Risk management and contingency planning.

 If a software team adopts a proactive approach to risk, avoidance is always

the best strategy. This is achieved by developing a plan for risk mitigation.

 There are three issues of RMMM

 Actions to be taken in the event that mitigation steps have failed and
the risk has become a live problem

 Devise RMMP(Risk Mitigation Monitoring And Management Plan)

RMMM Plan:

 Risk Avoidance(mitigation) Proactive planning for risk avoidance. This is

achieved by developing a plan for risk mitigation.

 Risk Monitoring what factors can we track that will enable us to determine
if the risk is becoming more or less likely?

 Assessing whether predicted risk occur or not

Dept of Computer Science & Engineering

Software Engineering 10

 Ensuring risk aversion steps are being properly applied

 Collection of information for future risk analysis

 Determine which risks caused which problems

 Risk Management what contingency plans do we have if the risk becomes a

reality?

 Contingency planning

 A risk management strategy can be included in the software project plan or

the risk management steps can be organized into a separate Risk Mitigation,
Monitoring and Management Plan. The RMMM plan documents all work
performed as part of risk.

 Each risk is documented individually by using a Risk Information Sheet.

 RIS is maintained using a database system.

Dept of Computer Science & Engineering

Software Engineering 11

Quality Management: Quality Concepts, Software Quality assurance, Software

Reviews, Formal Technical Reviews, Statistical Software Quality assurance,
Software Reliability, The ISO 9000 Quality standards.

 Quality management often called software quality assurance is an umbrella

activity that is applied throughout the software process.

 Quality management emcompasses

 A software quality assurance process

 Specific quality assurance and quality control tasks (including formal

technical reviews and a multi-tiered testing strategy)

 Effective software engineering practices (methods and tools)

 Control of all software work products and the changes made to them

 A procedure to ensure compliance with software development

standards

 Measurement and reporting mechanisms

Quality Concepts

 Defined as a characteristic or attribute of something

Refers to measurable characteristics that we can compare to known

standards

 In software it involves such measures as cyclomatic complexity, cohesion,

coupling, function points, and source lines of code

 Includes variation control

 A software development organization should strive to minimize the

variation between the predicted and the actual values for cost,
schedule, and resources

 They should make sure their testing program covers a known

percentage of the software from one release to another

 One goal is to ensure that the variance in the number of bugs is also
minimized from one release to another

 Two kinds of quality are sought out

 Quality of design

Dept of Computer Science & Engineering

Software Engineering 12

 Quality of conformance (i.e., implementation)

 Quality also can be looked at in terms of user satisfaction

User satisfaction = compliant product + good quality + delivery within budget
and schedule.

Quality Control

 Involves a series of inspections, reviews, and tests used throughout the

software process

 Ensures that each work product meets the requirements placed on it

 Includes a feedback loop to the process that created the work product

This is essential in minimizing the errors produced

 Combines measurement and feedback in order to adjust the process when

product specifications are not met

 Requires all work products to have defined, measurable specifications to

which practitioners may compare to the output of each process

Quality Assurance

 Consists of a set of auditing and reporting functions that assess the

effectiveness and completeness of quality control activities

 Provides management personnel with data that provides insight into the
quality of the products

 Alerts management personnel to quality problems so that they can apply the
necessary resources to resolve quality issues

Cost of Quality

 Includes all costs incurred in the pursuit of quality or in performing quality-

related activities

 Is studied to

 Provide a baseline for the current cost of quality

 Identify opportunities for reducing the cost of quality

 Provide a normalized basis of comparison (which is usually dollars)

 Involves various kinds of quality costs

Dept of Computer Science & Engineering

Software Engineering 13

 Increases dramatically as the activities progress from

Prevention  Detection  Internal failure  External failure

Kinds of Quality Costs

 Prevention costs

 Quality planning, formal technical reviews, test equipment, training

 Appraisal costs

 Inspections, equipment calibration and maintenance, testing

 Failure costs – subdivided into internal failure costs and external failure
costs

 Internal failure costs

 Incurred when an error is detected in a product prior to shipment

 Include rework, repair, and failure mode analysis

 External failure costs

 Involves defects found after the product has been shipped

 Include complaint resolution, product return and replacement,

help line support, and warranty work

Software Quality Assurance:

"Conformance to explicitly stated functional and performance

requirements, explicitly documented development standards, and implicit
characteristics that are expected of all professionally developed software―

 Software quality is no longer the sole responsibility of the programmer

 It extends to software engineers, project managers, customers,

salespeople, and the SQA group

 Software engineers apply solid technical methods and measures,

conduct formal technical reviews, and perform well-planned software
testing

The SQA Group:

 Serves as the customer's in-house representative

Dept of Computer Science & Engineering

Software Engineering 14

 Assists the software team in achieving a high-quality product

 Views the software from the customer's point of view

 Does the software adequately meet quality factors?

 Has software development been conducted according to pre-established

standards?

 Have technical disciplines properly performed their roles as part of the

SQA activity?

 Performs a set of of activities that address quality assurance planning,

oversight, record keeping, analysis, and reporting

SQA Activities:

• Prepares an SQA plan for a project

• Participates in the development of the project's software process description

• Reviews software engineering activities to verify compliance with the defined

software process

• Audits designated software work products to verify compliance with those

defined as part of the software process

• Ensures that deviations in software work and work products are documented
and handled according to a documented procedure

• Records any noncompliance and reports to senior management

• Coordinates the control and management of change

• Helps to collect and analyze software metrics

Software Reviews:

Purpose of Reviews

 Serve as a filter for the software process

 Are applied at various points during the software process

 Uncover errors that can then be removed

 Purify the software analysis, design, coding, and testing activities

Dept of Computer Science & Engineering

Software Engineering 15

 Catch large classes of errors that escape the originator more than other
practitioners

 Include the formal technical review (also called a walkthrough or inspection)

 Acts as the most effective SQA filter

 Conducted by software engineers for software engineers

 Effectively uncovers errors and improves software quality

 Has been shown to be up to 75% effective in uncovering design flaws

(which constitute 50-65% of all errors in software)

 Require the software engineers to expend time and effort, and the
organization to cover the costs

Formal Technical Review:

 To uncover errors in function, logic, or implementation for any representation

of the software

 To verify that the software under review meets its requirements

 To ensure that the software has been represented according to predefined

standards

 To achieve software that is developed in a uniform manner

 To make projects more manageable

The Review Meeting

 Has the following constraints

 From 3-5 people should be involved

 Advance preparation (i.e., reading) should occur for each participant

but should require no more than two hours a piece and involve only a
small subset of components

 The duration of the meeting should be less than two hours

 Focuses on a specific work product (a software requirements specification, a

detailed design, a source code listing)

Dept of Computer Science & Engineering

Software Engineering 16

Activities before the meeting

 The producer informs the project manager that a work product is

complete and ready for review

 The project manager contacts a review leader, who evaluates the

product for readiness, generates copies of product materials, and
distributes them to the reviewers for advance preparation

 Each reviewer spends one to two hours reviewing the product and
making notes before the actual review meeting

 The review leader establishes an agenda for the review meeting and
schedules the time and location

Activities during the meeting

 The meeting is attended by the review leader, all reviewers, and the
producer

 One of the reviewers also serves as the recorder for all issues and
decisions concerning the product

 After a brief introduction by the review leader, the producer proceeds to

"walk through" the work product while reviewers ask questions and
raise issues

 The recorder notes any valid problems or errors that are discovered; no
time or effort is spent in this meeting to solve any of these problems or
errors

Activities at the conclusion of the meeting

 All attendees must decide whether to

 Accept the product without further modification

 Reject the product due to severe errors (After these errors are
corrected, another review will then occur)

 Accept the product provisionally (Minor errors need to be

corrected but no additional review is required)

 All attendees then complete a sign-off in which they indicate that they
took part in the review and that they concur with the findings

Activities following the meeting

Dept of Computer Science & Engineering

Software Engineering 17

 The recorder produces a list of review issues that

 Identifies problem areas within the product

 Serves as an action item checklist to guide the producer in

making corrections

 The recorder includes the list in an FTR summary report

 This one to two-page report describes what was reviewed, who

reviewed it, and what were the findings and conclusions

 The review leader follows up on the findings to ensure that the

producer makes the requested corrections

Review Guidelines:

 Review the product, not the producer

 Set an agenda and maintain it

 Limit debate and rebuttal; conduct in-depth discussions off-line

 Enunciate problem areas, but don't attempt to solve the problem noted

 Take written notes; utilize a wall board to capture comments

 Limit the number of participants and insist upon advance preparation

 Develop a checklist for each product in order to structure and focus the
review

 Allocate resources and schedule time for FTRs

 Conduct meaningful training for all reviewers

 Review your earlier reviews to improve the overall review process

Statistical Software Quality Assurance:

Process Steps:

1. Collect and categorize information (i.e., causes) about software defects that
occur

2. Attempt to trace each defect to its underlying cause (e.g., nonconformance to

specifications, design error, violation of standards, poor communication with
the customer)

Dept of Computer Science & Engineering

Software Engineering 18

3. Using the Pareto principle (80% of defects can be traced to 20% of all causes),
isolate the 20% (the ―vital few‖ ).

4. Once the vital few causes have been identified, move to correct the problems
that have caused the defects.

This relatively simple concept represents an important step toward the

creation of an adaptive software process in which changes are made to improve
those elements of the process that introduce error.

A Sample of Possible Causes for Defects

 Incomplete or erroneous specifications (IES).

 Misinterpretation of customer communication (MCC).

 Intentional deviation from specifications (IDS).

 Violation of programming standards (VPS).

 Errors in data representation (EDR).

 Inconsistent component interface (ICI).

 Errors in design logic (EDL).

 Incomplete or erroneous testing (IET).

 Inaccurate or incomplete documentation (IID).

 Errors in programming language translation of design (PLT).

 Ambiguous or inconsistent human/computer interface (HCI).

 Miscellaneous (MIS).

Dept of Computer Science & Engineering

Software Engineering 19

Data Collection for Statistical SQA

Six Sigma

 Popularized by Motorola in the 1980s

 Is the most widely used strategy for statistical quality assurance

 Uses data and statistical analysis to measure and improve a company's

operational performance

 Identifies and eliminates defects in manufacturing and service-related

processes

 The "Six Sigma" refers to six standard deviations (3.4 defects per a million
occurrences) implying an extremely high quality standard.

 The Six Sigma methodology defines three core steps:

 Define customer requirements and deliverables and project goals via

well-defined methods of customer communication.

 Measure the existing process and its output to determine current

quality performance (collect defect metrics).

Dept of Computer Science & Engineering

Software Engineering 20

 Analyze defect metrics and determine the vital few causes.

 If an existing software process requires an improvement, Six Sigma suggests

two additional steps:

 Improve the process by eliminating the root causes of defects.

 Control the process to ensure that future work does not reintroduce
the causes of defects.

 Sometimes referred to as the DMAIC (define, measure, analyze, improve, and

control) method.

 If an organization is developing a software process (rather than improving an

existing process), the core steps are augmented as follows:

 Design the process to

 avoid the root causes of defects and

 to meet customer requirements.

 Verify that the process model will, in fact, avoid defects and meet
customer requirements.

 This variation is sometimes called the DMADV (define, measure, analyze,

design, and verify) method.

Software reliability:

Software Failure:

 Software failure is defined as “nonconformance to software requirements”.

 Given a set of valid requirements, all software failures can be traced to design
or implementation problems (i.e., nothing wears out like it does in hardware)

Software Reliability

 Software reliability is defined as “the probability of failure-free operation of

a software application in a specified environment for a specified time”.

 A simple measure of reliability is mean-time-between-failure (MTBF):

MTBF = MTTF + MTTR

where the acronyms MTTF and MTTR are mean-time-to-failure and

mean-time-to-repair, respectively.

Dept of Computer Science & Engineering

Software Engineering 21

Ex: MTBF = 68 days + 3 days = 71 days

Failures per 100 days = (1/71) * 100 = 1.4

Software Availability

 In addition to a reliability measure, we should also develop a measure of

avail-ability.

 Software availability is “the probability that a program is operating

according to requirements at a given point in time”. and is defined as

Availability = [MTTF/ (MTTF + MTTR)] * 100%

Ex : Availability = [68 days / (68 days + 3 days)] * 100 % = 96%

 The MTBF reliability measure is equally sensitive to MTTF and MTTR.

The availability measure is somewhat more sensitive to MTTR, an

indirect measure of the maintainability of software.

Software Safety

 Focuses on identification and assessment of potential hazards to software

operation

 It differs from software reliability

 Software reliability uses statistical analysis to determine the likelihood

that a software failure will occur; however, the failure may not
necessarily result in a hazard or mishap

 Software safety examines the ways in which failures result in

conditions that can lead to a hazard or mishap; it identifies faults that
may lead to failures

 Software failures are evaluated in the context of an entire computer-based

system and its environment through the process of fault tree analysis or
hazard analysis

The ISO 9000 Quality Standards:

ISO 9000 Quality Standard

 A quality assurance system may be defined as the organizational structure,

responsibilities, procedures, processes, and resources for implementing
quality management

Dept of Computer Science & Engineering

Software Engineering 22

 Quality assurance systems are created to help organizations ensure their

products and services satisfy customer expectations by meeting their
specifications.

 ISO 9000 describes quality assurance elements in generic terms that can be
applied to any business regardless of the products or services offered

 IS0 9001:200 Is the quality assurance standard that applies to software

engineering.

 The standard contains 20 requirements that must be present for an effective

quality assurance system.

 Because the ISO 9001:2000 standard is applicable to all engineering

disciplines a special set of ISO guidelines have been developed.

 The requirements delineated by ISO 9001:2000 address topics such as

management responsibility, quality system, contract review, design control,
document and data control, product identification and traceability, process
control, inspection and testing, corrective and preventive action, control of
quality standards, internal quality audits, training, servicing and statistical
techniques.

 For a software organization to become registered to IS0 9001:200,it must

establish policies and procedures to address each of the requirements noted
and then able to demonstrate that these policies and procedures are being
followed.

The SQA Plan:

SQA Plan Provides a road map for instituting software quality assurance in an
organization

 Developed by the SQA group to serve as a template for SQA activities that are
instituted for each software project in an organization

 A standard for SQA plans has been published by the IEEE.

 Structured as follows:

 The purpose and scope of the plan

 A description of all software engineering work products that fall within

the purview of SQA

Dept of Computer Science & Engineering

Software Engineering 23

 All applicable standards and practices that are applied during the
software process

 SQA actions and tasks (including reviews and audits) and their
placement throughout the software process

 The tools and methods that support SQA actions and tasks

 Methods for assembling, safeguarding, and maintaining all SQA-related

records

 Organizational roles and responsibilities relative to product quality

Dept of Computer Science & Engineering