MODULE - 05

Software Risk,
Configuration Management
RISK IDENTIFICATION
-Risk identification is a systematic attempt to
specify threats to the project plan(estimates,
schedule, resource loading, etc.).
-There are two distinct types of risks : generic
risks and product-specific risks.
→ Generic risks are a potential threat to
every software project.
→ Product-specific risks can be identified
only when the project plan and the
software statement of scope are
examined and an answer to the question
is developed:
"What special characteristics of this product
may threaten our project plan?"
● One method for identifying risks is to create a risk item checklist.
● The checklist can be used for risk identification and focuses on some subset of known and
predictable risks in the following generic subcategories:
●Product size
●Business impact
●Customer characteristics
●Process definition
●Development environment
●Technology to be built
●Staff size and experience
● Risk drivers that affect software risk components :
●Performance risk
●Cost risk
●Support risk
●Schedule risk
● The impact of each risk driver on the risk component is divided into one of four impact
categories—negligible, marginal, critical, or catastrophic.
 RISK ASSESSMENT

-Risk Assessment is a process of estimating

Assessment the probability and impact for each risk.
-The objective of the risk assessment is to
establish the magnitude or relevance of risks,
by considering both their eventual impact
and their likelihood of occurrence.
Economic Reputational Impact on -For impact purposes, both the economic
Impact Impact compliance impact and the reputational impact are
considered, as well as its potential impact on
compliance.
● involves the quantification and prioritization of all the risks.
● Effort is directed towards identifying the probability (possibility of occurrence) and impact
(the kind of loss which might result from the risk) of the detected risks.
● Low-Medium-High values are assigned to the probability and impact of each of the risks.
● Risks which end up getting ‘high’ for both probability as well as impact, are sorted to be
dealt first.
● For instance, risk such as a tight test schedule can be said to have high probability as well
as high impact. Thus, it should be on the top of the priority list.
● However, a risk such as natural disaster might have a medium to high impact, but its
probability is low. Hence, such a risk won’t make it to the top of the Risk Assessment list.
● Risk Assessment:-
→ Risk Identification - produces lists of the project-specific risk items likely to compromise
a project's success.
→ Risk Analysis - assesses the loss probability and loss magnitude for each identified
item, and it assesses compound risks in risk-item interactions.
→ Risk Prioritization - produces a ranked ordering of the risk items identified and
analyzed.
RISK PROJECTION
-Risk projection, also called risk estimation, attempts
to rate each risk in two ways—the likelihood or
probability that the risk is real and 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
activities:
(1) Establish a scale that reflects the perceived
likelihood of a risk.
(2) Delineate the consequences of the risk.
(3) Estimate the impact of the risk on the project
and the product.
(4) Note the overall accuracy of the risk projection
so that there will be no misunderstandings.
Developing Risk Table
→Steps in Setting up Risk Table
(1) Project team begins by listing all risks
in the first column of the table.
(Accomplished with the help of the risk
item checklists.)
(2) Each risk is categorized in the second
column. (e.g. PS implies a project size
risk, BU implies a business risk).
(3) The probability of occurrence of each
risk is entered in the next column of
the table.
(4) Individual team members are polled in
round-robin fashion until their
assessment of risk probability begins
to converge.
 Assessing Risk Impact

● Nature of the risk - the problems that are likely if it occurs. E.g. a poorly defined
external interface to customer hardware (a technical risk) will preclude early
design and testing and will likely lead to system integration problems late in a
project.
● Scope of a risk - combines the severity with its overall distribution (how much of
the project will be affected or how many customers are harmed?).
● Timing of a risk - when and how long the impact will be felt.
● Overall risk exposure, RE, determined using:
RE = P x C
P is the probability of occurrence for a risk.
C is the the cost to the project should the risk occur.
 RMMM MODEL
● Risk Mitigation :
-It is an activity used to avoid problems (Risk Avoidance).
-Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
● Risk Monitoring :
-It is an activity used for project tracking.
-It has the following primary objectives as follows.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
● Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This task is done by
Project manager when risk becomes reality and causes severe problems. If the project
manager effectively uses project mitigation to remove risks successfully then it is easier to
manage the risks. This shows that the response that will be taken for each risk by a manager.
The main objective of the risk management plan is the risk register. This risk register
describes and focuses on the predicted threats to a software project.

=> Drawbacks of RMMM:

● It incurs additional project costs.
● It takes additional time.
● For larger projects, implementing an RMMM may itself turn out to be another tedious project.
● RMMM does not guarantee a risk-free project, infact, risks may also come up after the project
is delivered.
 SOFTWARE CONFIGURATION MANAGEMENT
-Software Configuration Management(SCM) is the discipline for systematically controlling
the changes in software and supporting documents (like Test Cases, Test Plan, Design
Documents, SRS etc.) during the software development life cycle.
-Software configuration management is a process independent of the development process
largely because most development models cannot accommodate change at any time during
development.

-SCM can be considered as having three major components:

● Software configuration identification
● Change control
● Status accounting and auditing
1) Configuration identification:
The first requirement for any change management is to have clearly agreed-on basis for change. That is,
when a change is done, it should be clear to what changes has been applied. This requires baselines to be
established. A baseline change is the changing of the established baseline, which is controlled by SCM.
After baseline changes the state of the software is defined by the most recent baseline and the changes that
were made. Some of the common baselines are functional or requirements baseline, design baseline, and
product or system baseline. Functional or requirement baseline is generally the requirements document that
specifies the functional requirements for the software. Design baseline consists of the different components
in the software and their designs. Product or system baseline represents the developed system.
2) Change control:
Most of the decisions regarding the change are generally taken by the configuration control board (CCB),
which is a group of people responsible for configuration management, headed by the configuration manager.
For smaller projects, the CCB might consist of just one person. A change is initiated by a change request.
The reason for change can be anything. However, the most common reasons are requirement changes,
changes due to bugs, platform changes, and enhancement changes. The CR for change generally consists of
three parts. The first part describes the change, reason for change, the SCIs that are affected, the priority of
the change, etc.
3) Status accounting and auditing:
For status accounting, the main source of information is the CRs and FRs themselves. Generally, a field
in the CR/FR is added that specifies its current status. The status could be active, complete, or not
scheduled. Information about dates and efforts can also be added to the CR, the information from the
CRs/FRs can be used to prepare a summary, which can be used by the project manager and the CCB to
track all the changes.
SCM Repositories
=> Functions of an SCM Repository
● Data integrity
-Validates entries, ensures consistency, cascades modifications.
● Information sharing
-Shares information among developers and tools, manages and controls multi- user access.
● Tool integration
-Establishes a data model that can be accessed by many software engineering tools, controls
access to the data.
● Data integration
- Allows various SCM tasks to be performed on one or more CSCIS.
● Methodology enforcement
-Defines an entity-relationship model for the repository that implies a specific process model
for software engineering.
● Document standardization
-Defines objects in the repository to guarantee a standard approach for creation of software
engineering documents.
 SCM Features
● Versioning
- Save and retrieve all repository objects based on version number.
● Dependency tracking and change management
-Track and respond to the changes in the state and relationship of all objects in the
repository.
● Requirements tracing
-(Forward tracing) Track the design and construction components and deliverables that
result from a specific requirements specification.
-(Backward tracing) Identify which requirement generated any given work product.
● Configuration management
-Track a series of configurations representing specific project milestones or production releases.
● Audit trails
-Establish information about when, why, and by whom changes are made in the repository.
 SCM Process

● Concentric layers (from inner to outer)

-Identification
-Change control
-Version control
-Configuration auditing
-Status reporting

● CSCIS flow outward through these layers during their

life cycle.

● CSCIS ultimately become part of the configuration of one or more versions of a software
application or system.

CSCIs => Concentric S/W Configuration Items

● Identification
-Identification separately names each CSCI & organizes it in the SCM repository using object-oriented
approach.
-Objects start out as basic objects and are then grouped into aggregate objects.
-Each object has a set of distinct features that identify it :
-A name that is unambiguous to all other objects.
-A description that contains CSCI type, a project identifier, and change and/or version information.
-List of resources needed by the object.
-The object realization (i.e., the document, the file, the model, etc.).
● Change Control
-Change control is a procedural activity that ensures quality and consistency as changes aRSITY made
to a configuration object.
-An engineering change order (ECO) is issued for each approved change request :
-Describes the change to be made, the constraints to follow, and the criteria for review and audit.
-The baselined CSCI is obtained from the SCM repository :
-Access control governs which software engineers have the authority to access and modify a
particular configuration object.
-Synchronization control helps to ensure that parallel changes performed by two different people
don't overwrite one another.
● Version Control Task
-Version control is a set of procedures and tools for managing the creation and use of
multiple occurrences of objects in the SCM repository.
-Required version control capabilities :
-An SCM repository that stores all relevant configuration objects.
-A version management capability that stores all versions of a configuration object (or
enables any version to be constructed using differences from past versions).
-A make facility that enables the software engineer to collect all relevant configuration
objects and construct a specific version of the software.
-Issues tracking (bug tracking) capability that enables the team to record and track the
status of all outstanding issues associated with each configuration object.
-The SCM repository maintains a change set :
-Serves as a collection of all changes made to a baseline configuration.
-Used to create a specific version of the software.
-Captures all changes to all files in the configuration along with the reason for changes
and details of who made the changes and when.
● Configuration Audit
-Configuration auditing is an SQA activity that helps to ensure that quality is maintained as
changes are made.
-It complements the formal technical review and is conducted by the SQA group.
-It addresses the following questions :
-Has the change specified in the ECO been made? Have any additional modifications been
incorporated?
-Has a formal technical review been conducted to assess technical correctness?
-Has the software process been followed, and have software engineering standards been
properly applied?
-Has the change been "highlighted" and "documented" in the CSCI? Have the change data
and change author been specified? Do the attributes of the configuration object reflect
the change?
-Have SCM procedures for noting the change, recording it, and reporting it been followed?
-Have all related CSCIS been properly updated?
-A configuration audit ensures that :
-The correct CSCIS (by version) have been incorporated into a specific build.
-That all documentation is up-to-date and consistent with the version that has been built.
● Status Reporting
-Configuration status reporting (CSR) is also called status accounting.
-Provides information about each change to those personnel in an organization with a need
to know.
-Answers what happened, who did it, when did it happen, and what else will be affected?
-Sources of entries for configuration status reporting :
-Each time a CSCI is assigned new or updated information.
-Each time a change is approved by the CCB and an ECO is issued.
-Each time a configuration audit is conducted.
-The configuration status report :
-Placed in an on-line database or on a website for software developers and maintainers
to read.
-Given to management and practitioners to keep them appraised of important changes
to the project CSCIS.
 SOFTWARE QUALITY ASSURANCE
● Software quality assurance (SQA) is a process that ensures that
developed software meets and complies with defined or standardized
quality specifications.
● SQA is an ongoing process within the software development life cycle
(SDLC) that routinely checks the developed software to ensure it
meets desired quality measures.
● Rather than checking for quality after completion, SQA processes
tests for quality in each phase of development until the software is
complete. With SQA, the software development process moves into
the next phase only once the current/previous phase complies with
the required quality standards.
● SQA generally works on one or more industry standards that help in
building software quality guidelines and implementation strategies.
These standards include the ISO 9000 and capability maturity model
integration (CMMI).
 SQA Task & Plan
=> SQA Planning:
o A SQA Plan revolves around making sure that the product or service teaches the market trouble and bug-free.
It should also meet the requirements defined in the SRS (software requirement specification).
o The purpose of an SQA plan is three-fold. It comprises the following:
● Establishing the QA responsibilities of the team in question
● Listing areas of concern that need to be reviewed, audited and looked at
● Identifies the SQA work products
o Quality planning is the process of developing a quality plan for a project.
o The quality plan should set out the desired software qualities and describe how these are to be assessed.
o The SQA Plan provides a road map for instituting software quality assurance.
o A standard for SQA plans has been published by the IEEE. The standard recommends a structure that identifies:
(1) The purpose and scope of the plan
(2) A description of all software engineering work products (e.g., models, documents, source code)
(3) All applicable standards and practices that are applied during the software process
(4) SQA actions and tasks including reviews and audits) and their placement throughout the software process
(5) The tools and methods that support SQA actions and tasks
(6) Software configuration management procedures
(7) Methods for assembling, safeguarding, and maintaining all SQA- related records
(8) Organizational roles and responsibilities relative to product quality
=> Following TASKS / activities are performed by an independent SQA group:
1. Prepares an SQA plan for a project: The program is developed during project planning and is reviewed by all
stakeholders. The plan governs quality assurance activities performed by the software engineering team and
the SQA group. The plan identifies calculation to be performed, audits and reviews to be performed,
standards that apply to the project, techniques for error reporting and tracking, documents to be produced by
the SQA team, and amount of feedback provided to the software project team.
2. Participates in the development of the project's software process description: The software team selects a
process for the work to be performed. The SQA group reviews the process description for compliance with
organizational policy, internal software standards, externally imposed standards (e.g. ISO-9001), and other
parts of the software project plan.
3. Reviews software engineering activities to verify compliance with the defined software process: The SQA
group identifies, reports, and tracks deviations from the process and verifies that corrections have been made.
4. Audits designated software work products to verify compliance with those defined as a part of the
software process: The SQA group reviews selected work products, identifies, documents and tracks
deviations, verify that corrections have been made, and periodically reports the results of its work to the
project manager.
5. Ensures that deviations in software work and work products are documented and handled according to a
documented procedure: Deviations may be encountered in the project method, process description,
applicable standards, or technical work products.
6. Records any noncompliance and reports to senior management: Non- compliance items are tracked until
they are resolved.
 McCall’s Quality Factors
-McCall’s Software Quality Model was introduced in 1977. This
model is incorporated with many attributes, termed as software
factors, which influence software.
-The model distinguishes between two levels of quality attributes:
●Quality Factors: The higher-level quality attributes which can be
accessed directly are called quality factors. These attributes are
external attributes. The attributes at this level are given more
importance by the users and managers.
●Quality Criteria: The lower or second-level quality attributes that
can be accessed either subjectively or objectively are called
Quality Criteria. These attributes are internal attributes. Each
quality factor has many second-level of quality attributes or
quality criteria.
-This model classifies all software requirements into 11 software quality factors.
-The 11 factors are organized into three product quality factors: Product Operation, Product Revision, and
Product Transition.
1. Product Operation
-It includes five software quality factors, which are related to the requirements that directly affect the operation of the
software such as operational performance, convenience, ease of usage, and correctness. These factors help in
providing a better user experience.
● Correctness: The extent to which software meets its requirements specification.
● Efficiency: The number of hardware resources and code the software, needs to perform a function.
● Integrity: The extent to which the software can control an unauthorized person from accessing the data or
software.
● Reliability: The extent to which software performs its intended functions without failure.
● Usability: The extent of effort required to learn, operate and understand the functions of the software.

2. Product Revision
-It includes three software quality factors, which are required for testing and maintenance of the software. They
provide ease of maintenance, flexibility, and testing effort to support the software to be functional according to the
needs and requirements of the user in the future.
● Maintainability: The effort required to detect and correct an error during the maintenance phase.
● Flexibility: The effort needed to improve an operational software program.
● Testability: The effort required to verify software to ensure that it meets the specified requirements.

3. Product Transition
-It includes three software quality factors, that allow the software to adapt to the change of environments in the new
platform or technology from the previous.
● Portability: The effort required to transfer a program from one platform to another.
● Re-usability: The extent to which the program’s code can be reused in other applications.
● Interoperability: The effort required to integrate two systems with one another.
 SOFTWARE RELIABILITY
-Reliability is a measurable system attribute so non-functional reliability requirements may be
specified quantitatively.
-These define the number of failures that are acceptable during normal use of the system or the time
in which the system must be available.
● Functional reliability requirements define system and software functions that avoid, detect or
tolerate faults in the software and so ensure that these faults do not lead to system failure.
● Software reliability requirements may also be included to cope with hardware failure or
operator error.
-Reliability :
The probability of failure-free system operation over a specified time in a given environment for a
given purpose.
-Availability :
The probability that a system, at a point in time, will be operational and able to deliver the
requested services.
-Both of these attributes can be expressed quantitatively e.g. availability of 0.999 means that the
system is up and running for 99.9% of the time.
➔ Product Metrics
➔ Project Metrics *Refer from Chp.03*

➔ Product Metrics
➔ Fault & Failure Metrics
-The below are the methods used, based on the required
type of metric analysis, during the software development
phases :
●Mean Time to Failure – (Total time) / (Number of units
tested)
●Mean Time to Repair – (Total time for maintenance) /
(total repairs)
●Mean Time Between Failure – MTTF + MTTR
●Rate of Occurrence of Failure – 1 / (MTTF)
●Probability of Failure – (Number of Failures) / (Total
cases considered)
●Availability – MTTF / MTBF
FORMAL TECHNICAL REVIEW
● A FTR is a software quality assurance activity performed by software engineers with the following objectives:
-to uncover errors in function, logic or implementation of the software ;
-to verify that the software meets its requirements ;
-to ensure that the software has been developed according to the standards ;
-to achieve uniform software ;
-to make projects manageable.
● Each FTR is conducted as a meeting and is considered successful only if it is properly planned, controlled and
attended.
● The Review Meeting: Each review meeting should be held considering the following constraints-
Involvement of people:
1. Between 3, 4 and 5 people should be involve in the review.
2. Advance preparation should occur but it should be very short that is at the most 2 hours of work for
every person.
3. The short duration of the review meeting should be less than two hour. Gives these constraints, it should
be clear that an FTR focuses on specific (and small) part of the overall software.
At the end of the review, all attendees of FTR must decide what to do.
1. Accept the product without any modification.
2. Reject the project due to serious error (Once corrected, another app need to be reviewed), or
3. Accept the product provisional (minor errors are encountered and should be corrected, but no additional
review will be required).
The decision was made, with all FTR attendees completing a sign-of indicating their participation in the review
and their agreement with the findings of the review team.
● Review guidelines :- Guidelines for the conducting of formal technical reviews should be
established in advance. These guidelines must be distributed to all reviewers, agreed upon, and then
followed. A review that is unregistered can often be worse than a review that does not minimum set of
guidelines for FTR.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
5. Allocate resources and time schedule for FTRs in order to maintain time schedule.
6. Conduct meaningful training for all reviewers in order to make reviews effective.
7. Reviews earlier reviews which serve as the base for the current review being conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
10. Limit debate and rebuttal.
 WALKTHROUGH
-Method of conducting informal group/individual review is called walkthrough, in which a designer or
programmer leads members of the development team and other interested parties through a software
product, and the participants ask questions and make comments about possible errors, violation of
development standards, and other problems or may suggest improvement on the article, walkthrough can be
pre planned or can be conducted at need basis and generally people working on the work product are involved
in the walkthrough process.
-The Purpose of walkthrough is to:
• Find problems
• Discuss alternative solutions
• Focusing on demonstrating how work product meets all requirements.
-IEEE 1028 recommends three specialist roles in a walkthrough:
• Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and
who is often the Author).
• Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the
walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session.
• Author: who presents the software product in step-by-step manner at the walk-through meeting, and is
probably responsible for completing most action items.