SEPM-Module 4

Presented by,
Dr. Neethu Anna Sabu
• Risk is uncertain events associated with future events that have a probability of
occurrence but it may or may not occur and if occurs it brings loss to the project.
• Risk identification and management are very important tasks during software
project development because the success and failure of any software project
depend on it.
• Project risks: These risks threaten the project plan, potentially
causing schedule slippage and increased costs.
• They involve problems related to budget, schedule, personnel
(staffing and organization), resources, stakeholders, and
requirements.
• Project complexity, size, and the degree of structural uncertainty
are also considered project (and estimation) risk factors
• Technical risks: These risks threaten the quality and timeliness of
the software.
• If they materialize, implementation may become difficult or
impossible.
• Technical risks include potential problems with design,
implementation, interfaces, verification, and maintenance.
• Business risks: These risks threaten the viability of the software
and can jeopardize the project or the product. Examples of
business risks include:
• Building a product that no one wants (market risk).
• Building a product that no longer aligns with the company's overall
business strategy (strategic risk).
• Building a product that the sales force doesn't know how to sell
(sales risk).
• Losing senior management support due to changes in focus or
personnel (management risk).
• Losing budgetary or personnel commitment (budget risks)
• Risks can also be categorized by their predictability:
• Known risks: These can be uncovered through careful evaluation
of the project plan, the business and technical environment, and
other reliable information sources (e.g., unrealistic delivery dates,
lack of documented requirements).
• Predictable risks: These are extrapolated from past project
experiences (e.g., staff turnover, poor customer communication).
• Unpredictable risks: These are difficult to identify in advance and
can occur unexpectedly
• Based on the impact on software risk components, the following
types of risks can be identified:
• Performance risk: The uncertainty that the product will meet its
requirements and be fit for its intended use.
• Cost risk: The uncertainty that the project budget will be
maintained.
• Support risk: The uncertainty that the software will be easy to
correct, adapt, and enhance.
• Schedule risk: The uncertainty that the project schedule will be
maintained and the product will be delivered on time
• Risks related to software failure in the field can also occur after
the software has been delivered. These are associated with
software safety and hazards
 Risk identification
• Risk identification is a systematic attempt to specify threats to the
project plan (estimates, schedule, resource loading, etc.).
• By identifying known and predictable risks, the project manager takes
a first step towards avoiding them when possible and controlling
them when necessary.
• 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—risks associated with the overall size of the software
to be built or modified.
• Business impact—risks associated with constraints imposed by
management or the marketplace.
 RISK IDENTIFICATION
• Customer characteristics—risks associated with the sophistication of
the customer and the developer's ability to communicate with the
customer in a timely manner.
• Process definition—risks associated with the degree to which the
software process has been defined and is followed by the development
organization.
• Development environment—risks associated with the availability and
quality of the tools to be used to build the product.
• Technology to be built—risks associated with the complexity of the
system to be built and the "newness" of the technology that is packaged
by the system.
• Staff size and experience—risks associated with the overall technical
and project experience of the software engineers who will do the work.
• Below is the list of software development risk by Barry
Boehm- modified version.
• Assessing Overall Project Risk: This involves answering key
questions related to management and stakeholder commitment.
• Risk Components and Drivers: Identifying risk drivers that affect
software risk components like performance, cost, support, and
schedule is crucial.
• Brainstorming: Encouraging all team members to list potential
risks
Assessing Overall Project Risk
 Risk Components and Drivers
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.
RISK PROJECTION
• Risk projection, also called risk estimation, attempts to rate
each identified risk in two primary ways:
• (1) the likelihood or probability that the risk is real and
• (2) the consequences of the problems associated with the risk,
should it occur.
• You perform risk projection in collaboration with other managers
and technical staff
• There are four key steps involved in risk projection:
• [Link] a scale that reflects the perceived likelihood of a risk. This
involves defining categories or numerical values to represent how
probable a risk is.
• [Link] the consequences of the risk. This step focuses on
understanding what negative outcomes might happen if the risk
materializes.
• [Link] the impact of the risk on the project and the product. This
involves assessing the severity of the consequences in terms of project
aspects like schedule, cost, performance, and support. Impact
categories can range from negligible to catastrophic.
• [Link] the overall accuracy of the risk projection to avoid
misunderstandings. This involves evaluating the confidence level in the
probability and impact assessments.
• A risk table provides a simple technique for risk projection. It
typically includes the following columns:
• A list of all identified risks.
• The category of each risk (e.g., project size risk, business risk).
• The probability of occurrence for each risk, often expressed as a
percentage.
• The impact of each risk, which can be assessed for different risk
components (performance, support, cost, schedule) using defined
categories. An overall impact value can be determined by averaging
the impact across these components.
• A column to indicate the Risk Mitigation, Monitoring, and
Management (RMMM) category or a pointer to the RMMM plan
• After populating the risk table, it is typically sorted by probability
and by impact to prioritize risks.
• High-probability, high-impact risks rise to the top, indicating where
management should focus its attention.
• A cutoff line can be defined to determine which risks will receive
further management attention
• Risk projection and analysis are applied iteratively as the
software project progresses.
• The project team should revisit the risk table regularly, re-
evaluating each risk because new circumstances can cause its
probability and impact to change.
• This iterative process may also lead to adding new risks, removing
irrelevant ones, and adjusting the relative positions of existing
risks in the table
• The ultimate intent of risk projection steps is to prioritize risks so that
resources can be allocated effectively to address the most significant
threats to the project
SCM
• Configuration management is the art of identifying, organizing, and controlling
modifications to the software being built by a programming team.
• The goal is to maximize productivity by minimizing mistakes
• Software configuration management (SCM) is an umbrella activity that is
applied throughout the software process.
• Because change can occur at any time, SCM activities are developed to
• (1) identify change,
• (2) control change,
• (3) ensure that change is being properly implemented, and
• (4) report changes to others who may have an interest.
• Software configuration management is a set of tracking and control
activities that begin when a software engineering project begins and
terminate only when the software is taken out of operation.
• Software Configuration Management (SCM) repository is a
centralized database that stores all software configuration items (SCIs)
produced during the software development lifecycle, such as source
code, design documents, requirements specifications, and test
documents
• It addresses the challenges of managing these items, which were
historically maintained as paper documents
• The SCM repository serves as a hub for integrating various software
engineering tools and is central to the flow of the software process
• It ensures data integrity, sharing, and integration among team members
• To achieve this, the repository's structure and functionality are defined by a meta-
model (Defines the structure, rules, and behavior of the repository to ensure
consistency and reliability.)
 Key features of an SCM repository include:
• Versioning: Saving all versions of work products to manage releases and allow
rollback to previous states.
• Dependency tracking and change management: Managing relationships
between data elements and tracking changes to maintain information integrity.
• Configuration auditing: Recording when, why, and by whom changes are
made.
• Support for various object types: Managing text, graphics, and complex
documents.
• Mechanism for assembling version-specific configurations
• Branching and Merging
• Allows multiple development branches.
• Supports merging of different branches into a single main version.
• Tool Support
• Modern SCM repositories use tools like Git, SVN, Mercurial, and Perforce.
• Supports integration with CI/CD pipelines for automation.
• Types of SCM Repositories
• Centralized SCM (e.g., SVN, Perforce)
• Uses a single central server.
• All changes must be committed to the central repository.
• Distributed SCM (e.g., Git, Mercurial)
• Each developer has a full copy of the repository.
• Changes can be committed locally before being merged into the main repository.
• Popular SCM Tools (Modern Extensions)
• Git (Used with GitHub, GitLab, Bitbucket)
• Subversion (SVN)
• Perforce
• Mercurial
• Key objectives of SCM
[Link] the evolution of software systems: SCM helps to ensure that changes to a
software system are properly planned, tested, and integrated into the final product.
[Link] collaboration and coordination: SCM helps teams to collaborate and
coordinate their work, ensuring that changes are properly integrated and that everyone
is working from the same version of the software system.
[Link] version control: SCM provides version control for software systems,
enabling teams to manage and track different versions of the system and to revert to
earlier versions if necessary.
[Link] replication and distribution: SCM helps to ensure that software systems
can be easily replicated and distributed to other environments, such as test, production,
and customer sites.
SCM is a critical component of software development, and effective SCM practices can
help to improve the quality and reliability of software systems
• Importance of Software Configuration Management
[Link] Bug Tracking: Linking code modifications to issues that have been
reported, makes bug tracking more effective.
[Link] Deployment and Integration: SCM combines with continuous
processes to automate deployment and testing, resulting in more dependable and
timely software delivery.
[Link] management: SCM lowers the chance of introducing critical flaws by assisting
in the early detection and correction of problems.
[Link] for Big Projects: Source Code Control (SCM) offers an orderly method to
handle code modifications for big projects, fostering a well-organized development
process.
[Link]: By recording precise versions of code, libraries, and dependencies,
source code versioning (SCM) makes builds repeatable.
[Link] Development: SCM facilitates parallel development by enabling several
developers to collaborate on various branches at once.