WELCOME

Software Engineering[210253]

Prof. K. S. Mulani
Assistant Professor
Dept. Of Computer Engineering,
Sinhgad Institute of Technology, Lonavala
ksm.sit@sinhgad.edu
Cell. +91 7350020786
 Unit 5 - Risks and Configuration Management

• Risk Management: Software Risks, Risk Identification, Risk

Projection, Risk Refinement, Risk Mitigation, Monitoring, and
Management, The RMMM Plan.

• Software Configuration Management: Software Configuration

Management, The SCM Repository The SCM Process,
Configuration Management for any suitable software system.

• Suggested Free Open Source Tools: CF Engine Configuration

Tool, Puppet Configuration Tool.

7
 Risk Management
• 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

It aims at reducing the impact of all kinds of risk that may

effect a project by identifying, analyzing and managing
them.
3
 Risk Management
Reactive Vs Proactive risk Management
prevention action is considered as proactive and
corrective action is considered as reactive
Reactive :
It monitors the projects, likely risk and
resources are set aside.
Proactive:
Risk are identified, their probability and
impact is assessed
4
 Software Risk
It involve 2 characteristics

1. Uncertainty : Risk may or may not happen

2. Loss : Unwanted loss or consequences will occur

• It includes
1)Project Risk
2)Technical Risk
3)Business Risk
4)Known Risk
5)Unpredictable Risk
6)Predictable Risk 5
 Software Risk
• 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 in advance.
6
 Software Risk Management

• Major steps involved-

1. Risk Identification

2. Risk Projection

3. Risk Refinement

7
 Risk Identification
It concerned with identification of risk
Step1: Identify all possible risks
Step2: Create item check list
Step3: Categorize into risk components-Performance risk,
cost risk, support risk and schedule risk
Step4: Divide the risk into one of 4 categories
1. Negligible-0
2. Marginal-1
3. Critical-2
4. Catastrophic-3 (causing sudden and very great harm or
destruction)
8
 Risk Identification
Risk Identification includes
• Product size
• Business impact
• Development environment
• Process definition
• Customer characteristics
• Technology to be built
• Staff size and experience

9
 Risk Projection
• Also called risk estimation
• It estimates the impact of risk on the project
and the product
• Estimation is done by using Risk Table
• Risk projection addresses risk in 2 ways
• Likelihood or probability that the risk is
real(Li)

10
 Risk Projection
• Steps in Risk projection
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.

3) The probability of occurrence of each risk is entered in the next

column of the table. The probability value for each risk can be
estimated by team members individually.

4) Individual team members are polled in round-robin fashion until

their assessment of risk probability begins to converge.
11
 Risk Projection
Risk Category Probability Impact RMMM

Size estimate
may be
PS (project size) 60% 2
significantly
low

Larger no. of
users than PS 30% 3
planned

Less reuse than

PS 70% 2
planned

End user resist BU (business

40% 3
system risk)

12
 Risk Projection

• The impact of each risk is assessed by Impact

values

Catastrophic-1

Critical-2

Marginal-3

Negligible-4
13
 Risk Refinement
• Also called Risk assessment

• Refines the risk table in reviewing the risk impact

based on the following three factors

a. Nature: Likely problems if risk occurs

b.Scope: Just how serious is it?

c. Timing: When and how long

14
 Risk Refinement

• It is based on Risk Elaboration

• Calculate Risk exposure RE=P*C

Where P is probability and C is cost of project if

risk occurs

15
Risk Mitigation Monitoring And Management (RMMM)

• Its goal is to assist project team in developing a

strategy for dealing with risk

• There are three issues of RMMM

1)Risk Avoidance

2)Risk Monitoring and

3)Risk Management

16
 Risk Mitigation Monitoring And Management (RMMM)
Risk Mitigation - Risk mitigation simply means to reduce
adverse effects and impact of risks that are harmful to project and
Business continuity.
Proactive planning for risk avoidance

It is an activity used to avoid problems (Risk Avoidance).

Steps for mitigating the risks as follows.

➢ Finding out the risk.

➢ Removing causes that are the reason for risk creation.

➢ Controlling the corresponding documents from time to time.

➢ Conducting timely reviews to speed up the work. 17

 Risk Mitigation Monitoring And Management (RMMM)

• 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

18
Risk Mitigation Monitoring And Management (RMMM)
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

19
software project.
 RMMM plan
• It documents all work performed as a part of risk
analysis.

• Each risk is documented individually by using a

Risk Information Sheet.

• RISK is maintained by using a database system

RMMM Case Study

20
 What is Change Management
Also called software configuration management (SCM)

• It is an umbrella activity that is applied throughout the software

process

• It's goal is to maximize productivity by minimizing mistakes caused

by confusion when coordinating software development

• SCM identifies, organizes, and controls modifications to the

software being built by a software development team

• SCM activities are formulated to identify change, control change,

ensure that change is being properly implemented, and report
changes to others who may have an interest
21
 What is Change Management (continued)
• SCM is initiated when the project begins and terminates
when the software is taken out of operation
• View of SCM from various roles

– Project manager -> an auditing mechanism

– SCM manager -> a controlling, tracking, and policy making

mechanism

– Software engineer -> a changing, building, and access control

mechanism

– Customer -> a quality assurance and product identification

mechanism 22
Why do we need Configuration management?

• There are multiple people working on software which is continually

updating

• It may be a case where multiple version, branches, authors are involved in

a software config project, and the team is geographically distributed and
works concurrently

• Changes in user requirement, policy, budget, schedule need to be

accommodated.

• Software should able to run on various machines and Operating Systems

• Helps to develop coordination among stakeholders

• SCM process is also beneficial to control the costs involved in making

changes to a system.
23
 Software Configuration
• The Output from the software process makes up the software
configuration
– Computer programs (both source code files and executable files)

– Work products that describe the computer programs (documents targeted at

both technical practitioners and users)

– Data (contained within the programs themselves or in external files)

• The major danger to a software configuration is change

– First Law of System Engineering: "No matter where you are in the system
life cycle, the system will change, and the desire to change it will persist
throughout the life cycle"
24
 The SCM Repository
Paper-based vs. Automated Repositories
• Problems with paper-based repositories (i.e., file cabinet containing
folders)
– Finding a configuration item when it was needed was often difficult
– Determining which items were changed, when and by whom was often
challenging
– Constructing a new version of an existing program was time consuming
and error prone
• Today's automated SCM repository
– It is a set of mechanisms and data structures that allow a software team
to manage change in an effective manner
– It acts as the center for both accumulation and storage of software
engineering information
– Software engineers use tools integrated with the repository to interact
with it
25
 Automated SCM Repository (Functions and Tools)

Requirements
Versioning
tracing

SCM Repository
Functions :
Data integrity
Dependency Configuration
Information sharing
tracking Tool integration management
Data integration
Methodology enforcement
Document standardization

Change Audit
management trails

(Explained on next two slides)

26
 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(Computer Software Configuration Item)
• 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 27
 Toolset Used on a Repository
• 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
– Track the design and construction components and deliverables that
result from a specific requirements specification
– 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

28
 The SCM Process
Primary Objectives of the SCM Process

• Identify all items that collectively define the software configuration

• Manage changes to one or more of these items

• Facilitate construction of different versions of an application

• Ensure the software quality is maintained as the configuration

evolves over time

• Provide information on changes that have occurred

29
 SCM Tasks
Status reporting

Configuration auditing

Version control

Change control

Identification

SCI SCI
SCI
SCI

(More on next slide)

30
 SCM Tasks (continued)
• 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

31
 Identification Task
• Identification separately names each CSCI and then organizes it in the
SCM repository using an 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 the 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.)

32
 Change Control Task
• Change control is a procedural activity that ensures quality and consistency as changes are
made to a configuration object

• A change request is submitted to a configuration control authority, which is usually a

change control board (CCB)
– The request is evaluated for technical merit, potential side effects, overall impact on other
configuration objects and system functions, and projected cost in terms of money, time, and
resources

• 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
33
 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 34
 Configuration Auditing Task
• 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? 35
 Status Reporting Task
• 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

• 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 36
 Configuration Management For WebApp

Dominant Issues

• General strategies for SCM are applicable, but tactics

(policies) and tools must be adapted to conform to unique
nature of WebApp.

• Four issues should be considered when developing tactics

for WebApp configuration management.
 Configuration Management For WebApp (Conti)
Content : A WebApp contains a vast array of content – text, graphics, applets,
etc.

• The challenge is to organize this content into rational set of configuration

objects and then establish appropriate configuration control mechanism for
these objects.

• One approach is to model the WebApp content using conventional data

modeling techniques, attaching a set of specialized properties to each object
that are required to establish an effective SCM approach.

People : Any person involved in the WebApp can create content.

Many content creator have no SE background and are unaware of need of CM.
As a consequence, the application grows and changes in an uncontrolled
fashion.
 Configuration Management For WebApp (Conti)
3. Scalability : As the size and complexity grows, small changes can have far-
reaching and unintended effects that can be problematic. Therefore, the rigor
(inflexibility) of configuration control mechanisms should be directly proportional to
application scale.

4. Politics : “Who owns the WebApp?” The answer to this question has a significant
impact on the management and control activities.

There are some questions which help to understand the politics associated with Web
Engineering:

1. Who assumes the responsibility for accuracy of information on the website?

2. Who is responsible for making change?

3. The answers to these questions help determine the people within an organization
who must adopt a configuration management process for WebApp.
 WebApp Configuration Objects
• WebApp encompasses a broad array of configuration objects : content objects
(text, audio, video), functional components (scripts, applets), and interface
objects (CORBA).

• WebApp objects can be identified in any manner but some conventions are
followed to ensure that cross-platform compatibility is maintained.

Conventions:

• Filename should be limited to 32 chars, underscore in file name should be

avoided, mixed-case and all-caps should be avoided.

• URL references within a configuration object should use relative path (e.g.
../products/alarm.html).

• Content structure defines a content architecture; i.e, it defines the way in which
content objects are assembled.
 CF Engine Configuration Tool
• CFEngine is an open-source configuration management tool that allows you
to automate the configuration and maintenance of large-scale IT
infrastructures.

• It uses a declarative language to describe the desired state of a system, and

then applies the necessary changes to bring the system into compliance with
that state.

• CFEngine includes a powerful configuration tool, called the "CFEngine

Policy Hub," which provides a web-based interface for configuring,
monitoring, and reporting on your CFEngine policies.

• With this tool, you can easily create, edit, and manage policies, and monitor
their status across your entire IT infrastructure.
 CF Engine Configuration Tool
• Policy management: The tool allows you to create, edit, and manage
policies, including creating policy templates and applying policies to specific
hosts or groups of hosts.

• Monitoring: The CFEngine Policy Hub provides real-time monitoring of

your CFEngine policies, so you can quickly identify and address any issues
that arise.

• Reporting: You can generate reports on the status of your CFEngine

policies, including compliance status, policy violations, and system health.

• Automation: The CFEngine Policy Hub includes automation features that

allow you to automate common tasks, such as deploying new policies and
updating existing policies.
 Puppet Configuration Tool
• Puppet is a configuration management tool that is widely used in software
engineering to manage the configuration of IT infrastructure.

• It allows administrators to automate the provisioning, configuration, and

management of servers and applications across their entire infrastructure,
using a single source of truth.

• Puppet is based on a client-server architecture, where the Puppet master

server is responsible for managing the configuration of the client nodes.

• The configuration is defined using Puppet's own declarative language,

which allows administrators to specify the desired state of their
infrastructure, rather than the specific steps required to achieve that state.
Some of the key features of Puppet include:

1.Declarative language: Puppet's declarative language allows administrators to

specify the desired state of their infrastructure, rather than the specific steps required
to achieve that state.

2.Resource abstraction: Puppet provides a high-level abstraction of IT resources,

such as packages, services, and files, making it easy to manage them across different
platforms and operating systems.

3.Idempotent operations: Puppet's operations are idempotent, meaning that they can
be repeated without changing the end result, making it easy to enforce the desired
configuration.

4.Puppet Forge: Puppet Forge is a repository of modules that can be used to extend
Puppet's functionality, making it easy to reuse and share code across different teams
and organizations.

5.Reporting and auditing: Puppet provides detailed reporting and auditing

capabilities, allowing administrators to track changes to their infrastructure and
ensure compliance with security and regulatory standards.
Thank you