Chapter 6 - Configuration Management

Question 1

Define Configuration.

Answer 1

The sum total of all the artifacts, their current state and the dependencies between them is called the configuration.

Question 2

What is the risk of making a change to an artefact?

Answer 2

• impact all the artefact’s dependencies if you make a change
• if not careful may leave the configuration in an inconsistent state
• risk changing one module without changing it’s dependant modules so that the configuration is is inconsistent
• e.g a change to the requirement impacts will have an impact on the system design and all of the code modules that depend on the design. Also, the testing plan, test cases and testing scripts for the code will also be impacted.

Question 3

What is the point of configuration management?

Answer 3

to establish processes and set up repositories to manage change properly without losing overall consistency.

Question 4

What are the 4 aims of configuration management?

Answer 4

1. to identify all items that collectively will make up the configuration
2. to manage changes to one or more of these items so that the collection remains consistent
3. to manage different versions of the product
4. to assure software quality as the configuration evolves over time

Question 5

What are the 5 key configuration tasks that meet the configuration aims?

Answer 5

1. identification — where the configuration items necessary for the project are identified
2. version control — where processes and tools are chosen to manage the different versions of configuration items as they are developed
3. change control — where changes to that affect more than just one configuration item are managed
4. configuration auditing — where the consistency of the configuration is checked
5. configuration reporting — where the status of configuration items is reported.

Question 6

Define configuration items

Answer 6

The entire set of artefacts produced in the project

Question 7

What are the 3 types of configuration items?

Answer 7

1. basic objects
2. aggregate
3. derived
   For example, we may choose classes to be basic objects stored in files in a repository. The program is the aggregate object also stored in a file but dependent on the objects of which it is composed. When we compile the program we generate a derived object — the executable — which is also stored in a file but is derived from the program and object files.

Question 8

What are aggregate objects?

Answer 8

Aggregate objects are composed of atomic objects or other aggregate objects.

Question 9

What are derived objects?

Answer 9

Derived objects are generated from atomic and aggregate objects by tools.

Question 10

What is the aim of identifying configuration items?

Answer 10

to determine what configuration items will be produced in the project and how they will be managed.

Question 11

What is version control?

Answer 11

Version control refers to managing the different versions of all the configuration objects in the project.

Question 12

What does version control usually consist of?

Answer 12

1. a repository for storing configuration items;
2. version management functions that allow software engineers to create and track versions, and roll the system back to previous versions if necessary; and
3. ideally a make facility that allows engineers to collect all of the configuration objects for a particular target together and to build that target.

Question 13

What tools should be used to maintain SCM information?

Answer 13

• in a repository or configuration database.
• Be wary of tools such as CVS as they may only store information on versions and not the dependencies between different configurations items.

Question 14

Define version.

Answer 14

An instance of a model, document, code, or other configuration item which is functionally distinct in some way from other system instances.

Question 15

Define variant.

Answer 15

An instance of a system which is functionally identical but non-functionally distinct from other instances of a system.

Question 16

Define release.

Answer 16

An instance of a system which is distributed to users outside of the development team.

Question 17

Define derivation history.

Answer 17

This is a record of changes applied to a configuration object.

Question 18

What should each change in the derivation history ideally record?

Answer 18

• the change made
• the rationale for the change
• who made the change
• when it was implemented

Question 19

What are ways of tracking versions in a repository?

Answer 19

• version tracking
• attributes
  In practice, a version also needs an associated name for easy reference and typically both numbered and attribute style of version tracking are used.

Question 20

Explain version tracking to track versions in a repository.

Answer 20

• through version numbering, in which versions are num- bered and tagged.
• the actual numbers typically have no meaning on their own but take meaning from the overall management of configuration objects.
• For example, major version numbers represent reviewed versions while minor version numbers represent small un-reviewed changes.

Question 21

Explain the use of attributes to track versions in a repository.

Answer 21

• Examples of attributes include: Date; Creator; Programming Language; Customer; and Status.
• attributes should uniquely identify the version of the configuration object but this is not always the case.
• are more flexible for searching and retrieving configuration objects because we do not need to remember how the version number corresponds to the attributes of the configuration object.
• set of attributes have to be chosen carefully so that all versions can be uniquely identified.

Question 22

What is the change management plan?

Answer 22

The change management plan is developed as part of an overall configuration management plan specifically to control these changes to the configuration.

Question 23

How should changes be made?

Answer 23

in a way that allows everyone on the project team to find out:

• exactly what changes need to be made
• what they need to do to affect the change
• why the change is being made
• how it will impact them.
• some changes may need to be carefully negotiated so that everyone understands the need for the change and supports it

Question 24

Define baseline.

Answer 24

A baseline is an artifact that is stable. That is, it has been formally reviewed and agreed upon, that is now ready for use in future development, and can only be changed through formal change management procedures.

Question 25

Explain how baselines work.

Answer 25

Assume we have a software configuration item SCI. First we extract it from the repository and then perform our engineering tasks using the SCI. We may make frequent changes to the SCI while doing this but at some point the engineering task concludes and we are left with a modified SCI ready to be baselined. If the SCI passes the formal review then it can be added to the stable configuration items already in the repository. If it does not pass the review then it must be reworked until it does. Other project team members only work with the baselined stable SCIs. Once baselined any further changes need to go through the formal change process.

Question 26

What are configuration audits?

Answer 26

Configuration audits complement the other configuration management activities by assuring that what is in the repository is actually consistent and that all of the changes have been made properly.