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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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 developthe 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
K.PRAVEENA
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
K.PRAVEENA
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
standards
to
ensure
compliance
with
software
development
 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
K.PRAVEENA
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 qualityrelated 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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
organization to cover the costs
effort, and
the
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
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
K.PRAVEENA
Software Engineering
Ex:
21
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 availability.
 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
K.PRAVEENA
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 notedand 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
K.PRAVEENA
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
K.PRAVEENA