Slide 1: Chap 9: Software Configuration Management Change is inevitable, and it creates confusion when it is not analyzed, recorded, reported and controlled.
Definition: The art of coordinating Software Development to minimize.... confusion.
It is important because if you don't control the change, it controls you i.e. Uncontrolled changes can turn a very well-run software project into chaos.
It is a set of activities designed to control change by identifying the work products that are likely to change,establishing relationships among them, defining mechanisms for managing them and reporting the changes imposed. Slide 2: SCM Activities: Identify Change.
Ensure that the change is being properly implemented.
Report Changes to others who may have an interest.
Actually, all tracking and control activities that begin when a software engineering project begins and terminate only when the software is taken out of operation. Slide 3: New business or market conditions which change product requirements.
New customer needs demand modification of data, functions and services given by a product.
Reorganization or business growth causes changes in project priorities.
Scheduling constraints cause a redefinition of the system. Fundamental sources of change Slide 4: SCM major tasks and concepts Software Configuration Items(SCIs)?
SCI is an information that is created as part of the software engineering process.
A SCI is document, an entire suite of test case, or a named program component(e.g. A c++ function).
SCIs are organized to form Configuration objects that may be cataloged in the project database with a single name. Slide 5: Configuration objects Composition relation Interrelationship Slide 6: SCM major tasks and concepts Baselines:
A baseline is SCM concept to control change without seriously impeding justifiable change.
According to IEEE:
“A specification or a 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”
Anology: kitchen doors in a restaurant. Slide 7: Baselines SCIs and the project Databases Slide 8: The SCM process The SCM is an important element of software quality
assurance. Its primary responsibility is the control of
change. It is also responsible for identification of
individual SCIs and various versions of software, the
auditing of software configuration to ensure that it
has been properly developed, and the reporting of all
changes applied to configuration.
There are some questions which lead to five SCM tasks:
identification, version control, change control,
configuration auditing and reporting. Slide 9: Identification of objects in the
software configuration To manage SCIs they must be separately named and
organized usingobject-oriented approach.
There are two types of objects:
Basic objects: A unit of text that has been created
by a software engineer during analysis, design, code,
or test. E.g. A source listing for a component.
Aggregate objects: A collection of basic objects and
other aggregate objects. E.g. Design Specification.
Each object has a set of distinct features that identify
it uniquely: a name, a description, a list of resources,
and a realization. Slide 10: The object name is character string, the object
description is a list of data items that identify
The SCI type(e.g. Document ,program, data) represented by the object.
A project identifier
Change and/or version information. Resources are “entities that are provided, processed, referenced or otherwise required by the object”. e.g.Data types, specific functions.
The realization is the pointer to the “unit of text” for a basic object and null for an aggregate object. Slide 11: The relationships can also be shown that exist between named objects. E.g.
E-R diagram 1.4 <part-of> data model;
data model <part-of> data specification;
data model <interrelated> data flow model;
data model <interrelated> test case class m;
The interrelationships between objects can be represented with Module Interconnection Language MIL.
It describes the interdependencies among configuration objects and enables any version of a system to be constructed automatically. Slide 12: The Evolution Graph The evolution graph describes the change history of an object. How the developer refers documents and test cases for a particular version?, How can we be sure that changes to a version's source code is properly reflected in corresponding design documentation? The key element to answers are identification.
Now a variety of SCM tools are available for identification like for getting the previous versions the changes are subtracted from the recent version. Slide 13: An example of an Evolution Graph Slide 14: Version Control It combines all procedures and tools to manage different versions of configuration objects that are created during software process.
SCM allows user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating attributes with each version, and then allowing a configuration to be specified by describing the set of desired attributes.
Can be shown through: Evolution Graph and Object Pool Slide 15: A Simple program example A program is composed of entities 1,2,3,4,5. Entity 4 is used only when the software uses color displays. Entity 5 is used when it uses monochrome display.
We have here two versions :
1. entities 1,2,3,4
2. entities 1,2,3,5 Slide 16: Object Pool Slide 17: Change Control As given by James Bach:
Change is annoying because a tiny change in code can cause a big failure, but also enables wonderful new capabilities.
Uncontrolled change could cause chaos in big projects. Slide 18: Engineering change order Slide 20: Configuration Audit How can we ensure that the change has been properly implemented?
By 1.formal technical reviews-focuses on the technical correctness of the modified configuration object.
2.Software configuration Audit-Assesses the configuration object for characteristics that are generally not reviewed.It asks and answers:
1. Has the change specified in ECO made?Have the modifications incorporated?
2. Has a formal technical review been conducted to assess tecnical correctness?
3. Has the software process and SE Standards followed?
4. Has the change highlighted in SCI?
5. Have all related SCIs been updated? Slide 21: Status Reporting It is a task that answers :
Who did it?
When did it happen?
What else will be affected?
Each time an SCI is updated,change is approved by CCA(change control auhority),a configuration audit is conducted, a CSR entry is made.
It helps the developers and maintainers by improving communication among them? Slide 22: SCM standards Many SCM standards have been proposed.
MIL-STD-483,DOD-STD-480A and MIL-STD-1521A focused on softwares for military applications.
ANSI/IEEE stds no. 828-1983,no. 1042-1987,no. 1028-1988[IEEE94] are applicable for non military software and are recommended for both large and small SE organizations.