To provide insight about configuring software and its management

1. 1

2. Topics To Be Covered
Need for change in Software Configuration?
Software configuration management
process
Working of SCM
Goals of SCM
2

3. Learning Outcomes
After reading this module students will be able
to:
 Understand the need for change in software
configuration
 Learn software configuration management process
 Knowledge about working of SCM and
 Know about ultimate goals of SCM
3

4. Need for change in
Software Configuration?
They missed a requirement: - A stakeholder will
be working with an existing system and realize that
it’s missing a feature.
People change their minds for many reasons, and do
so on a regular basis. This happens because:-
They identified a defect: - A bug, or more
importantly the need to address the bug, should also
be considered a requirement.
4

5. The market place change: - Perhaps a
competitor will release a new product which
implements a features that your product
doesn’t.
Legislation change: - Perhaps new
legislation require new features, or changes
to existing features, in your software.
5

6. They realized they didn’t understand
their actual needs: - It’s common to show
a stakeholder your working system to date
only to have them realize that what they
asked really isn’t what they want after all.
This is one reason why active stakeholder
participation and short iterations are to
your success.
6

7. Software configuration
management process
7

8. Software consists of a collection of items, such as
program data, and documentation that can be easily
changed. These changes do happen and often. The
easily changeable nature of software and the fact that
changes often take place requires that changes take
place in a controlled manner. Software configuration
management (SCM) is the discipline for
systematically controlling the changes that takes
place during development. Software configuration
management is change control activity.
8

9. The basic reason for having SCM, as with any other
activities for the project, is that has beneficial for
effective on cost, schedule, and quality of product
being developed. Changes and rework require for
the changes, can have an enormous adverse effect
on the cost and quality of the product being
developed. The fundamental reason for having the
SCM process is to control the changes so that they
have minimal effect on cost, schedule, and quality.
9

10. Working Under
SCM
Under
Review
Rejected
Developer Satisfied
Approved
Working of SCM
10

11. Configuration identification: - The first
requirement for any change management is to have
clearly agreed on basic for change. That is, when a
changes is done, it should be clear to what the
changes have been applied.
Change control: - Once the SCI’s are identified and
their dependencies understood, the change control
procedures of SCM can be applied. Most of the
decisions regarding the changes are generally taken
by the Configuration Control Board (CCB), which is
group of responsible for configuration management,
headed by the Configuration Manager (CM).
11

12. Requirements change management process:-
These requirement changes can result in scope
change on the project. Since requirement changes
are nearly inevitable, it is best to prepare to deal with
changes rather than be surprised when they occur
and try to resist them. Requirements changes are one
of the major reasons for software-intensive system
failures. Most of requirement related problem
emerge as result of changing requirement (RCM)
process model have been proposed in the literature.
12

13. Requirement change management:-
The customers expect modern software to be evolved
and sufficiently flexible to accommodate changing
user’s needs. This expectation, however, is untendered
by the fact that changing requirements are recognized
as major causes of project failure. This may also have a
degrading effect on the under laying design of system.
The fact of life is that software requirement changes
and involve from inception of development.
Hence, changes to requirements are carefully traced,
analyzed and their effect on the overall system are
properly assessed.
13

14. The requirement change process should include the
following activities to be carried out when a change is
needed in the requirements.
•Allocating adequate resource (Assignment of
Responsibilities)
•Analysis of requirement changes (Management of
changes)
•Documenting requirement changes (Documentation)
•Establishing team communication (Communication of
Change)
•Creating requirements traces throughout the project
lifecycle from inception to the final products
(Requirement traceability
Establishing a baseline for requirement specification
(Establishment of baseline)
14

15. Assignment of responsibility:-
All changes should be approved or rejected by the
competent authority for the project. It may be project
manager, project lead may other equivalent person.
After the decision, work is further given to individual
to carry out desired modifications.
Management of changes:-
It is an important activity of implementation of any
changes. Whenever a request is received for any
addition/modification a change request is created
through a specified request form. The request is
analyzed due to its impact overall project cost,
resources allocated and delivery schedule for project.
15

16. Documentation: - It is required to keep track of
every activity of the project. Success of any
software project lies in the documentation. It is
very pertinent to note that without
documentation, project future is dark and with
every passing day, it leads towards disaster.
Requirement traceability: - It is a technique to
provide relationship between requirements,
design implementation in order to manage the
effect of change and its impact on the success of
the project. Every requirement traceable any
and every piece of design work may be traced to
one or more requirement in the project.
16

17. Communication of change: - The most problematic changes
to the requirement specification have been the ones that are
not communicate to every stakeholder. Communication
failures typically occur when we may drop a feature or
change a performance requirement without communication
to other.
Establishment of baseline: - After the approval of change, it
is communicated to all. If every stakeholder agrees to change,
it is implemented and tested. Baseline is tested version of a
set of requirements represent a conceptual milestone, serves
as the basis for further development. The steps for baseline
establishment are:-
•Approval for change from competent authority.
•Communicate the approval to all stakeholders.
•History of changes maintained.
17

18. Goals of
SCM
18

19. The goals of SCM benefits the organization in four
major ways:
Control: SCM offers the opportunity to review,
approve, and incorporate changes to the
configuration item. It provides a standard method
for change, maintenance, traceable changes, and
controlled changes to the baseline of the
configuration item.
Management: SCM provides a process of
automatic identification and guidance of
configuration items in their whole life cycle.
19

20. Cost Savings: Throughout the whole life cycle of a
configuration item cost savings can be realized by
using SCM. By actively defining, tracing, and
auditing configuration items, failures can be
detected early, and corrective action can be taken.
No confusion in task division can occur.
Quality: Deliverables are checked continuously
during the software development process. By
checking the human-work in an automated way,
the level of compliance of deliverables with
predefined requirements can be maximized.
20

21. Software Configuration Management
Process Activities
21

22. Software Configuration Management is
known as a very complicated process.
Therefore a practical example of a
tangible product can enlarge the insight
of the practitioner. The next steps are a
walkthrough through the SCM process
for the firmware of a mobile phone. We
will focus on the software that has to be
written for the functioning of the device.
22

23. SCM process for the mobile phone
23

24. SCM Process Management: The goal of this project is
to design a single platform firmware for a family of
mobile phones of one vendor. Some functionality is
given as constraint, even as some milestones on the
timeline of the process. Guidelines are retrieved from
earlier firmware development processes, and are for
example that a small core-functionality should be
designed initially which is extended with more
functions later on. The SCM plan is created and
describes which activities should be passed through
and procedures for some sub activities are set.
24

25. Software Configuration Identification: A basic set of
software artefacts are identified as configuration
items, in this example classes for the mobile OS. The
company selects IBM Rational Clear Case as the SCM
Tool, and implements a compatible software library to
store the configuration items, and later on their
versions, and technical documentation. Relationships
between objects in the software library are identified.
25

26. Software Configuration Control: An external
actor, e.g. a customer, complains about a bug in
the firmware. This complaint is converted to a
change request, which is approved by the SCCB.
The required changed are implemented to the old
version, and a new version is placed into the
library. The Configuration Identification phase is
now repeated to check if this version should be
stamped as new ‘baseline’.
26

27. Software Configuration Status Accounting: The
project manager keeps track of the development
process. He frequently creates reports with status
information. When he identifies shortcomings, or
interpretation failures, he directly gives feedback to
the responsible software developers to correct it.
27

28. Software Configuration Audit & Validation: An
independent body of software engineers frequently audits
the new software versions, and validates if those versions
are confirm the prevailing regulations and guidelines. For
example if the requested Bluetooth-functionality is only
available to the intended mobile phones in the family. The
audit team can consist of engineers from another project
team (e.g. other mobile phone family).
28

29. Software Release Management & Delivery: When the
project manager identifies a completed status in the
status accounting phase, it is time to build the releases
of each member of the mobile phone software family.
After building, internal tests at the manufacturer can be
conducted, where after external delivery consist of nice
looking boxes, user documentation, and the phone
including software.
29