Software Configuration Items

We have already described a software configuration item as information which is developed as part of the software engineering procedure. In the extreme an SCI could be considered to be a single section of a huge specification or one test case in a huge suite of tests. For more realistically an SCI is a document and fully suite of test cases or a named program component example for an Ada95 package  or a C++ function.

There are the  following SCIs which become  the  goal  for  configuration management methods and  form  a  set  of baselines:

1.  System Specification

2.  Software Project Plan

3.  Software Requirements Specification

a.  Graphical analysis models

b.  Process specifications

c.   Prototype

d.    Mathematical specification

4.  Preliminary User Manual

5.  Design Specification

a.  Data design description

b.  Architectural design description

c.   Module design descriptions

d.    Interface design descriptions

e.   Object descriptions if object-oriented methods are used

6.  Source Code Listing

7.  Test Specification

a.  Procedure and Test plan

b.  Recorded results and Test cases

8.  Installation Manuals and Operation

9.  Executable Program

a.  Module executable code

b.  Linked modules

10. Database Description

a.  File structure and Schema

b.  Initial Content

11.  As-built User Manual

12.  Maintenance Documents

a.  Software problem reports

b.  Maintenance requests

c.   Engineering change orders

13.  Procedures and Standards for Software Engineering

In the addition to the SCIs noted above various software engineering companies also place software tools under configuration control. Which is Specific edition of compilers, editors and other CASE tools are frozen as a part of the software configuration because these tools were used to produce documentation source code, and data which must be available when modification to the software configuration are to be made. While problems are rare it is possible that a new edition of a tool example for a compiler might produce various results than the real version. For this reason tools such as the software which they help to produce can be baseline as a part of a comprehensive configuration management procedure.

In real world, SCIs are organized to form configuration objects which may be catalogued in the project database with a single name. The configuration object has a name attributes and is connected to other objects through relationships. By the Figure the configuration data model, objects design specification, module N, source code, and test specification are each describe differently. Moreover each of the objects is associated to the others as illustrate through the arrows. In a diagram a curved arrow indicates a compositional relation which is data model and module N that are category of the object design specification. A double headed single arrow indicates an interrelationship. If a modification were made to the source code object interrelationships enable a software engineer to determine what SCIs and other objects might be affected.