The document discusses configuration management and software configuration management (SCM) concepts. It defines key SCM terms like baseline, software configuration item, and configuration. It describes the SCM process which includes identification, version control, change control, configuration auditing, and status reporting. Challenges of SCM in component-based software development are also covered. Effective SCM is important for software projects to manage changes and maintain integrity across software versions and releases.

1. Configuration Management

2. Why Is Software Difficult to
Build?
 Lack of control
 Lack of monitoring
 Lack of traceability
 Uncontrolled changes

3. Conflicts in Team Software
Development
 Simultaneous updates – how to
prevent one person from undoing the
changes of another
 Shared and common code – how to
notify everyone who needs to know
about a change
 Versions – how to make changes to all
affected versions when needed

4. Software Configuration Management
Basics
 Identification – identifying software
configuration items in a baseline
 Control – controlling the release of a product
and changes to it throughout its lifecycle
 Status Accounting – recording and reporting
of the status of components and changes
 Auditing and Reviewing – Validating the
completeness of a product and that SCM
procedures are being followed

5. SCM Definitions
 Baseline – One or more software
configuration items that have been
formally reviewed and agreed upon and
serve as a basis for further development
 Software Configuration Item – A collection
of software elements treated as a unit for
the purposes of SCM
 Configuration – A collection of all the
elements of a baseline and a description of
how they fit together

6. SCM Definitions (cont’d)
 Configuration Control Board – Group with the
responsibility for reviewing and approving
changes to baselines
 Software – All of the code, specifications, plans,
descriptions, processes, and documents
associated with a software development effort
 Version – A specific instance of a baseline or
configuration item

7. Examples of Configuration Items
 Product concept specification
 Software project plans
 Software requirements specifications
 Software design descriptions
 Source code
 Database descriptions
 SCM procedures
 Software release processes
 Software test documents
 User documentation
 Maintenance documentation

8. Version Control
 Allows different projects to use the same source
files at the same time
 Isolates work that is not ready to be shared by the
rest of the project
 Isolates work that should never be shared
 Allows software engineers to continue
development along a branch even when a line of
development is frozen

9. Change Control
 Proposed changes to baselines must have
some level of review
 The impact of proposed changes must be
identified and understood.
 When appropriate the approval of the CCB,
key managers and project members must be
obtained
 Approved changes must be properly
implemented
 After changes are made all affected parties
must be notified

10. Baseline Management
 What baselines are required to be defined and
managed?
 Typically aligned with major milestones
 Applies to documents as well as code
 How is the current software configuration
defined?
 A snapshot of everything the product has produced
at some point in time

11. Baseline Management (cont’d)
 Who must approve changes to baselines?
 Usually the Change Control Board (CCB)
 How and when are baselines created and
physically controlled?
 Through the use of document control systems, code
control tools, and procedures to prevent the making
of unapproved changes

12. Baseline Management (cont’d)
 How are people informed of changes?
 The CCB disseminates change information
 How are baselines verified?
 By reviews, inspections, and the testing of code
 Are baselines tied to project milestones?
 Many are, but during coding many may not be

13. Baseline Management (cont’d)
 What information is required to process a
change to a baseline?
 A description of the proposed changes
 Reasons for making the changes
 List of other items affected by the changes
 What tools, resources, and training are required
to perform baseline change assessment?
 File comparison tools to identify changes
 Resources and training depend on size and
complexity of project

14. Baseline Management (cont’d)
 What metrics should be used to assess changes
to a baseline?
 Complexity
 Average module size
 Number of modules changed
 Number of bugs fixed and verified
 Code coverage

15. Baseline Management (cont’d)
 How are unauthorized changes to source code
prevented, detected, and corrected?
 No way to prevent unauthorized changes
 Provide software engineers with training
 A commercial available SCM systems provide
adequate protection
 Unauthorized changes should be caught during
assessment procedures

16. Baseline Management (cont’d)
 What tools, resources, and training are required
to perform baseline management?
 A fully featured SCM tool
 On large projects a separate SCM group may be
needed
 SCM training is required for all involved in the
process

17. Workspace Management
 Software engineers need a consistent and
reproducible workspace area (a sandbox) in which
they can develop and debug their code
 They need to be able to share project files while
shielding the project from the instability of their
evolving code
 SCM tools should provide such a capability

18. Baseline Change Assessment
 Helps to identify recent changes that may be
responsible for problems
 Helps to ensure that only authorized changes are
made

19. Version Management
 Being able to reliably build and recreate versions
of a product as it evolves and after it is released.
 Being able to retreat to a previous version if
necessary
 Being able to recreate all versions of the product
that customers have

20. Types of Audits
 In-process audits – verify the consistency of
the design as it evolves through the
development process
 Functional audits – verify that functionality and
performance are consistent with requirements
defined in the SRS
 Physical audits – verify that the as-built
version of software and documentation are
internally consistent and ready for delivery
 Quality system audits – independent
assessment of the compliance to the software
QA plan

21. Configuration Status Accounting
Requirements
 Identifying the types of information that project
managers need
 Identifying the degree of control needed by
project management
 Identifying the reports required and the different
audiences for each report
 Identifying the information required to produce
each report

22. SCM Summary
 Change is inevitable
 Defined procedures are required to manage
change without preventing change
 Software presents many challenges from a
control, management, and tracking
perspective
 Knowing what you have and how you got
there is very important
 Being able to recreate exactly what is
delivered to customers is essential

23. SCM: AN OVERVIEW
SCM

24. Agenda
 Introduction
 Concepts
 CBSD

25. Agenda
 Introduction
 Concepts
 CBSD

26. Introduction
 Configuration management: the art of
coordinating software development to minimize
confusion
 Configuration management is the art of
identifying, organizing, and controlling
modifications to the software being built
 The goal is to maximize productivity by
minimizing mistakes

27. Introduction
 SCM is an umbrella activity that is applied
throughout the software process
 All information produced as part of the software
process are collectively called a software
configuration

28. Introduction
 First Law of System Engineering states: 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

29. Introduction
 Fundamental sources of change:
 New business or market conditions
 New customer needs
 Reorganization and/or business downsizing
 Budgetary or scheduling

30. Agenda
 Introduction
 Concepts
 CBSD

31. Concepts
 Baseline, IEEE defines a baseline as:
 A specification or product that has been formally
reviewed and agreed upon, that thereafter serves
as the basis for further development, and that can
be changed only through formal change control
procedures

32. Common Baselines
System engineering
Requirement analysis
Software design
Coding
Testing
Release
System specification
Software requirement specification
Design specification
Source code
Test plans/Procedures/Data
Operational system

33. Software Configuration Item
(SCI)
 Information created as part of SE process
 SCIs used as target in SCM:
 System specification
 Software project plan
 Software requirements specification
 Preliminary user manual
 Design specification
 Source code listing

34. Software Configuration Item
(SCI)
 Test specification
 Operation and installation manuals
 Executable program
 Database description
 As-built user manual
 Maintenance documents
 Standards and procedures for SE

35. SCI Modification Process
[Pressman, 1997]

36. Object identification in SW configuration
 SCI can be named and organized using OO
approach
 Two types of objects:
 basic object: ‘unit of text’ created during analysis,
design, coding, or testing.
 Aggregated objects: a collect of basic objects

37. Object identification in SW configuration
 Features of objects:
 name: a character string
 description: a list of data items to identify the SCI
type and a project id, version information, etc.
 resources: entity that are provided, processed,
referenced by the object
 Realization: a pointer to ‘unit of text’ for a basic object
or null for an aggregate object

38. Object identification in SW configuration
 Relationships between objects
 part-of: a hierarchical relationship
 interrelated: a cross-structural relationship
 Object identification methods
 evolution graph
 automated SCM tools
 module interconnection language

39. Configuration Objects
[Pressman, 1997]

40. SCM Process
 Identification
 Version control
 Change control
 Configuration auditing
 Status reporting

41. Configuration Control
 Enforces a rigorous change control mechanism
 Requires formal procedures to
 request changes
 carry out impact analysis
 approve changes
 carry out changes

42. Evolution Graph
obj
1.2
obj
1.4
obj
2.0
obj
1.3
obj
1.1.1
obj
1.1.2
obj
2.1
obj
1.0
obj
1.1
[Pressman, 1997]

43. Merging
 Two diverging versions may be merged to create
a single new version combining both set of
change requests.
 Merge operations are typically done interactively
with tool assistance

44. Version Control
 Some of the issues
 When an executable is built, the versions of its
constituents must be consistent.
 If A depends upon B and B is recompiled, A may also
need to be recompiled.
 What if multiple people need to modify same SCI?
 Need to know what version different customers have
 How do you keep track of 100’s or 1000’s of
modules?

45. Version Control
 Evolution graph to represent different versions
 Uses an object pool representing components,
variants and versions, and their relationship
 RCS (Revision Control System) is common tool.
 Use for documentation as well as code development
[Conradi, 1998]

46. Techniques for storing Versions
 Full files
 Forward Delta files
 Reverse Delta files
 The set of differences between two versions is
called a delta.
[Conradi, 1998]

47. Version Control Support
 At the language level (in Ada):
 If only body of B changes, no change to A
 If spec of B changes, A must be recompiled
Spec A
Body A
Spec B
Body B
With B;

48. Change Control
Change request from user
Developer evaluates
Change report is generated
Change control authority makes decision
Request is queued, persons are
assigned
“Check out” SCI(s)
Change request is denied
User is informed

49. Change Control
Make the change/review change
‘Check in’ changed SCIs
Establish a baseline for testing
Do SQA and ‘promote’ changes for inclusion in next
release
Rebuild appropriate version
Audit the SCI changes/ include changes in new
version
Release the new version

50. Access and Synchronization Control
[Pressman, 1997]

51. Configuration Audit
 Two approaches can be used to ensure proper
implementation of change:
 formal technical review (FTR)
 software configuration audit
 CA assesses a configuration object for characteristics
that are not generally not considered during review
 CA generally checks:
•SCM procedures followed
•all related SCIs properly updated
•change date and author
specified
•Changes incorporated
•FTR conducted
•SE standards
followed

52. Status Reporting
 Event occurred -- An SCI received updated ID
 people involved
 Time happened
 Effects on others
 Generated on a regular basis
 To improve communication among all parties

53. Organising for SCM
Roles:
 Configuration manager
 Change Control Board
includes representatives of
- user
- customer
- developer

54. SCM Planning
The SCM Plan is prepared in Project Initiation
phase. It documents
- what SCM activities are to be done
- how they are to be done
- who is responsible for doing specific
activities
- when they are to happen
- what resources are required

55. SCM Planning
 The outcome of the SCM planning phase is the
Software Configuration Management Plan
(SCMP), which might be extended or revised
during the rest of the project.
 The SCMP can either follow a public standard
like the IEEE 828, or an internal (e.g. company
specific) standard.

56. SCM Tools
Common features of popular PC-based tools
(PVCS, MS Visual SourceSafe):
 Support for controlling all types of files (source
code as well as binary)
 Managing changes as deltas
 Supporting branching and merging
 Identifying and re-creating releases
 Providing a project view

57. SCM Tools
[Conradi, 1998]

58. Research Tools
[Volzer, 2002]

59. Research Tools
[Volzer, 2002]

60. Outline of a Software Configuration
Management Plan (SCMP, IEEE 828-
1990)
1. Introduction
 Describes purpose, scope of application, key terms
and references
2. Management (Who?)
 Identifies the responsibilities and authorities for
accomplishing the planned configuration
management activities
3. Activities (What?)
 Identifies the activities to be performed in applying to
the project.

61. Outline of a Software Configuration
Management Plan (SCMP, IEEE 828-
1990)
4. Schedule (When?)
 Establishes the sequence and coordination of the
SCM activities with project mile stones.
5. Resources (How?)
 Identifies tools and techniques required for the
implementation of the SCMP
6. Maintenance
 Identifies activities and responsibilities on how the
SCMP will be kept current during the life-cycle of the
project.

62. Tailoring the SCMP
 The IEEE standard allows quite a bit of flexibility for
preparing an SCMP.
 To conform to the rest of the project, the SCMP may be
 tailored upward:
 to add information
 to use a specific format
 tailored downward:
 Some SCMP components might not apply to a particular project.
 Instead of omitting the associated section, mention its applicability.
 Information that has not been decided on at the time the SCMP is
approved should be marked as “to be determined”.

63. Conformance to the
IEEE Standard 828-1990
 Presentation format & minimum information:
 A separate document or a section embedded in
another document titled “Software Configuration
Management Plan”.
 6 sections: Introduction, Management, Activities,
Schedules, Resources and Plan Maintenance

64. Conformance to the
IEEE Standard 828-1990
 Consistency Criteria:
 All activities defined in the SCMP are assigned to
an organizational unit or person and they are
associated with resources to accomplish the
activities.
 All identified configuration items have defined
processes for baseline establishment and change
control.

65. Agenda
 Introduction
 Concepts
 CBSD

66. CBSD
 Like the traditional way to develop software,
CBSD also needs the support of SCM
 CBSD brings new challenges to SCM
[Mei, 2001]

67. CBSD
 Some identified issues:
 In CBSD, usually an application is implemented into
many many files
 A file is not a logical constituent in an CBSD
application
 Software architecture has been viewed as an
important milestone in the lifecycle of software
[Mei, 2001]

68. CBSD
 Difficults in CBSD to be solved by SCM
 Any change to a component must consider all
products that use this component– Often, each
change leads to a new version, rather than the
modification of an existing asset

69. CBSD
 According to [Mei, 2001], using files as the
primitive items and asking developers to operate
on the files directly are not an efficient way to
support CBSD

70. CBSD
 To support CBSD, SCM should solve the
following issues:
 Viewing each component as an entity and operating
on components
 Controlling the current modifications to each
component
 Managing component composition and
relationships between/among components

71. New trends
 Formal models
 Distinction between physical unit and logical
unit
 Two types of logical units: Primitive components
and composite components
 Some works for helping to extract information
from SCM systems like information related to
potential impact of a change, decision support
[Sahraoui, 2000]

72. New trends
 Works trying to measure changes impacts in the
system as whole and to track every fault to a
system element [Nikora, 2003]

73. Requirements/Assurances Contracts
[Rausch, 2000]

74. Requirements/Assurances Contracts
[Rausch, 2000]

75. Conclusions
 Components evolves so that it must be
monitored/managed
 SCM has to work with logical unit that be suitable
to CBSD development
 SCM has to have models to represent all kind of
important relations between/among components

76. Conclusions
 The SCM models must take into account how to
reasoning about system properties and make
predictions or forecastings
 The SCM tools are going to work at the
syntactical, semantic, and architectural levels

77. Risk Management
 "Tomorrow problems are today's risk." Hence, a
clear definition of a "risk" is a problem that could
cause some loss or threaten the progress of the
project, but which has not happened yet.
 These potential issues might harm cost, schedule
or technical success of the project and the quality
of our software device, or project team morale.
 Risk Management is the system of identifying
addressing and eliminating these problems
before they can damage the project.

78.  A software project can be concerned with a large
variety of risks. In order to be adept to systematically
identify the significant risks which might affect a
software project, it is essential to classify risks into
different classes. The project manager can then check
which risks from each class are relevant to the
project.

79. There are three main classifications of risks which can
affect a software project:
1. Project risks
2. Technical risks
3. Business risks

80. Project risks
 Project risks concern differ forms of
budgetary, schedule, personnel, resource,
and customer-related problems. A vital
project risk is schedule slippage. Since the
software is intangible, it is very tough to
monitor and control a software project. It is
very tough to control something which
cannot be identified. For any
manufacturing program, such as the
manufacturing of cars, the plan executive
can recognize the product taking shape.

81. Technical risks
 Technical risks concern potential method,
implementation, interfacing, testing, and
maintenance issue. It also consists of an
ambiguous specification, incomplete
specification, changing specification,
technical uncertainty, and technical
obsolescence. Most technical risks appear
due to the development team's insufficient
knowledge about the project.

82. Business risks
 This type of risks contain risks of building an
excellent product that no one need, losing
budgetary or personnel commitments, etc.

83. Principle of Risk Management
1. Global Perspective: In this, we review the bigger
system description, design, and implementation. We
look at the chance and the impact the risk is going
to have.
2. Take a forward-looking view: Consider the threat
which may appear in the future and create future
plans for directing the next events.
3. Open Communication: This is to allow the free
flow of communications between the client and the
team members so that they have certainty about the
risks.
4. Integrated management: In this method risk
management is made an integral part of project
management.
5. Continuous process: In this phase, the risks are
tracked continuously throughout the risk
management paradigm.

85. Risk Identification:
 The project organizer needs to anticipate the risk
in the project as early as possible so that the
impact of risk can be reduced by making effective
risk management planning.
 A project can be of use by a large variety of risk.
To identify the significant risk, this might affect a
project. It is necessary to categories into the
different risk of classes.

86. There are different types of risks
which can affect a software project:
1. Technology risks: Risks that assume from the
software or hardware technologies that are used to
develop the system.
2. People risks: Risks that are connected with the
person in the development team.
3. Organizational risks: Risks that assume from the
organizational environment where the software is
being developed.
4. Tools risks: Risks that assume from the software
tools and other support software used to create the
system.
5. Requirement risks: Risks that assume from the
changes to the customer requirement and the
process of managing the requirements change.
6. Estimation risks: Risks that assume from the
management estimates of the resources required to
build the system

87. Risk Analysis
 During the risk analysis process, you have to
consider every identified risk and make a
perception of the probability and seriousness of
that risk.
 There is no simple way to do this. You have to
rely on your perception and experience of
previous projects and the problems that arise in
them.

88. Risk Control
 It is the process of managing risks to achieve desired
outcomes. After all, the identified risks of a plan are
determined; the project must be made to include the
most harmful and the most likely risks. Different risks
need different containment methods. In fact, most
risks need ingenuity on the part of the project
manager in tackling the risk.

89. There are three main methods to
plan for risk management:
1. Avoid the risk: This may take several ways
such as discussing with the client to change the
requirements to decrease the scope of the
work, giving incentives to the engineers to avoid
the risk of human resources turnover, etc.
2. Transfer the risk: This method involves getting
the risky element developed by a third party,
buying insurance cover, etc.
3. Risk reduction: This means planning method
to include the loss due to risk. For instance, if
there is a risk that some key personnel might
leave, new recruitment can be planned.

90. Any question?