SOFTWARE QUALITY

MANAGEMENT
Define and Discuss Reactive and Proactive risk strategies used
software development.

Proactive Risk Management

● Proactive risk management is the analysis and management of risk that may affect a
given project before they occur.
● It involves:
○ Careful analysis of a situation to determine potential risks
○ Assessment of processes to determine potential risks.
○ Identification of drivers of risks in order to understand their root cause.
○ Assessment of the probability and impact of the risks in order to prioritize
them and prepare a contingency plan.
● It is implemented as a preventive measure and helps companies/organizations
prepare for the worst case scenario in case of a project.
● It improves an organization's ability to both avoid and/or manage both existing and
emerging risks.
● It also helps them to quickly adapt to unwanted events or crises.
● It should be implemented as a continuous process or discipline that has to be
practiced and made an integral part of the project or organization.

Reactive Risk Management

● Reactive Risk Management is one where threats are tackled as they emerge.
● Incidents are examined for their root cause to prevent similar threats from occurring
in future.
● It is considered to be just as important to an overall risk management strategy as
proactive risk management; and is often used to apply and enhance it.
● It helps organizations manage during events with unforeseen threats.
● During the mitigation of the threat, it uses and tests the processes outlined by the
proactive risk management.
Discuss risk mitigation techniques used in software
development. What is the limitation of each identified
technique?

Avoidance

● This is where the risk and it's negative consequences are completely avoided during
the Software Development Life Cycle.
● It can be done by designing out the causes of the risk or stepping away from the
business activities involved with the risk.
● This allows the organization to successfully avoid the undesired consequences of the
risk.
● Limitation
○ Avoidance of the risk may cause the project to be shut down altogether,
leading to wastage of resources gathered to undertake the project to begin
with.
○ Planning around the risk may take extra time and resources.

Acceptance

● For risks that are at an acceptable level; for instance, a sufficiently low estimated
failure rate of a device or software; the product can be allowed to ship regardless
with the risk accepted by the organization.
● Limitation
○ If the acceptance of the risk is based on estimates or predictions; incorrect
information or forecasting may lead to bad consequences in future.

Control and Reduction

● Through the use of risk prioritization tools to identify and prioritize risks; organizations
can reduce the probability of occurrence; or the severity of the consequences of an
unwanted risk.
● If it is not possible to reduce the likelihood that the risk will occur, or the severity of it's
consequences; then organizations can implement controls.
● These controls can be used to:
○ Detect the causes of unwanted risk prior to the threat occurring during use of
the product
○ Detect the root causes of unwanted failures that the team can avoid during
development.
● Limitation
○ Controlling risk can get expensive over time.

Transference
 ● This is where the burden of the risk consequence is shifted to another party.
● This can be done through giving the work of developing the product to another party,
or through the use of insurance.
● Limitation
○ Some control is given up, which may also affect the quality of the product.
○ A poor quality product may affect the brand's image despite the product not
being fully made by the company.

Explain goal question metric model as used in software

quality
● Goal Question Metric (GQM) is a method/approach used to identify important and
meaningful metrics in relation to software quality.

● It is done through :

○ Listing the goals or objectives of the process

○ Tracing the goals with data or metrics
○ Using a framework to interpret the data with respect to listed goals for the
process
○ It follows a top-down approach where:
■ The goals are first specified
■ The questions are then written and collected
■ Finally, metrics are associated with each question.
● It is made up of 3 Levels:

1. Conceptual level (Goal):

○ This level represents a given goal or objective.

○ A goal is an object or entity.
○ Objects of measurement include :
■ Products
■ Includes Software Requirement Specification (SRS), Program,
Code or Design.
■ Processes
■ Includes Designing and Testing
■ Resources
■ Includes Hardware and Software
● 2. Operational level (Question)

○ This level represents questions.

○ Here, a set of questions is used to assess the goal.
● 3. Quantitative level (Metric)

○ This level represents metrics.

 ○ With every question added in the Operational Level, a set of data (metrics) is
used to answer the question quantitatively.
○ This data can be of 2 types :
■ Objective
■ For example: The size of modules, Lines of code or size of the
program.
■ Subjective
■ For example: The level of user satisfaction on a scale.

What is software audit? What are the phases involved? Lastly,

identify types of audits that can be done on a software product.
● A software audit is an external or internal review of a software program.
●
● They are conducted in order to:
○ Check for the satisfaction of legal requirements
○ Check for compliance with industry standards
○ Monitor for quality assurance
○ Verify licensing compliance
● It is made up of four phases:
○ Planning
■ This is where everything in the auditing process is planned and
prepared.
■ It can be done by an auditor, the lead auditor, the audit program
manager, the organization itself or a combination of these so as to
ensure the audit complies with the objectives of the organization.
■ Any necessary approvals are taken by the auditing firm (or internally)
and relevant information is given to the organization being audited.
○ Execution
■ In this phase, there is the data gathering for the audit and it covers the
entire period right from arrival at the audit location up till the exit
meeting at the end of the audit.
■ It is made up of many activities including:
■ Meeting with the auditee
■ Understanding the requirements and Processes
■ Verifying the process against the standard operating
procedure.
○ Reporting
■ Once the audit is planned and executed by the Auditors; the
organization being audited is kept informed of the audit process
through regular status meetings.
■ In these meetings, the following are discussed:
■ Audit observations
■ Potential findings
■ Recommendations
○ Follow-Up
 ■ This is where proper closure is given to the audit by the corrective
action, and improvement or plan of action being given.

When are software reviews applicable? Identify various

types applied to enhance software quality.
● Software reviews are best applicable when one wishes to:
○ Make the process of testing the software time and cost effective.
○ To reduce the number of defects in the final software.
○ Improve the productivity of the development team.
○ To eliminate the inadequacies.
● There are mainly 3 types of software reviews:
○ Software Peer Review
■ This is the process of assessing the technical content and quality of
the product.
■ It is usually conducted by the author of the software together with
some other developers.
■ It is done to examine or resolve the defects in the software.
■ It is made up of the following types:
■ Code Review
○ The source code is examined systematically.
■ Pair Programming
○ This is where two developers develop code together
using the same platform.
■ Walkthrough
○ This is where the members of the development team
are guided by the authoring developer and ask
questions or make comments about defects.
■ Technical Review
○ This is where a highly qualified team of individuals
examines the software product and identify technical
defects according to standards and specifications.
■ Inspection
○ The reviewers follow a well-defined process to find
defects.
○ Software Management Review
■ This is where the work status is evaluated.
■ In this section, the decisions regarding downstream activities are
taken.
○ Software Audit Review
■ This is a type of external review whereby critics that aren’t part of the
development team conduct an independent inspection of the software
product in order to assess its compliance with stated standards and
specifications.
References

Bhasin, H. (2020, April 13). What is auditing? Four phases of the audit cycle.

Marketing91. https://www.marketing91.com/what-is-auditing-definition/

Geek for Geeks. (2019, April 10). Software engineering | software review.

GeeksforGeeks. https://www.geeksforgeeks.org/software-engineering-software-

review/

indeed. (2020, December 10). Five key risk mitigation strategies (with examples) |

indeed.com. Www.indeed.com. https://www.indeed.com/career-advice/career-

development/risk-mitigation-strategies

Jones, S. (2020, February 20). Proactive vs Reactive Risk Management Strategies.

Reciprocity. https://reciprocitylabs.com/proactive-vs-reactive-risk-management-

strategies/

MetricStream. (2019). MetricStream. Metricstream.com.

https://www.metricstream.com/insights/proactive-risk-management-approach.htm