Chapter 8 Advanced SCM Concepts

5. Interface Control In today's environment, interface design has become an important segment of the software engineering process. One is not only faced with the normal system-to-system interfaces, but other functions such as local area networks to wide area networks or workstations to files servers to mainframes. Those interfaces that affect the software are identified and documented by the systems analyst and, in turn, are placed under configuration control.

5. Interface Control An interface is the functional and physical characteristics required for a common boundary to exist between two or more software products and computer systems that are provided by different organizations or sources. Interface control is the process of identifying, documenting, and controlling all performance, functional, and physical attributes relevant to the interfacing of two or more products provided by one or more organizations.

5. Interface Control Interface documentation consists of interface control drawings or other documentation that depicts physical, functional, and test interfaces of related or co-functioning products . An interface control document defines the interfaces that may affect the operation of cofunctioning Cis and is used for control as well as delineating the interface criteria and technical detail necessary to effect an economical and viable interface

5. Interface Control For product interfaces external to the enterprise, the SCM system must establish an interface agreement and a mutually agreed-on documentation of common attributes. Product attributes include defined interfaces with products that are developed, produced, and supplied by organizations outside of the enterprise. External interfaces are documented in a product's configuration documentation.

5. Interface Control The procedures (for defining complex interfaces and coordinating proposed changes to them) may employ a joint interface control working group. A mutually agreed-on interface definition (including performance, functional, and physical attributes) is typically detailed in an interface document or drawing.

5. Interface Control NASA-DID-M200 provides for an interface control plan and states in simple terms that the purpose of the plan is to define the process by which the developer defines and manages all external interfaces between the software and all usersboth human and software.

5. Interface Control MIL-STD-483B states that interface control is the coordinated activity required to ensure that the functional and physical characteristics of systems and equipments are compatible [6]. The interface control activity is responsible for ensuring that the configuration identification conforms to the functional interfaces established by system engineering and that the affected CIs are logically compatible and can be operated and supported as needed.

5. Interface Control The interface activity is also responsible for the control of documentation, including an assessment of the impact of changes to control documentation or changes emanating from other document changes that could affect the interfaces.

5. Interface Control Most of the software specifications and documents define or explain the interfaces between the CI being identified and another CI or computer system. All of these interfaces must be mapped so that everyone on the project will understand what has been defined and will be able to carry out their specified tasks. SCM treats the interface design documents and drawings in the same manner as other documentation, except that SCM also provides for assessment of impacts to interfacing entities.

5. Interface Control The days of one organization developing all of the components of a system are long gone. This is the era of distributed development, where development teams from around the world and from different organizations work jointly to produce a software system. In such cases, an interface control working group (ICWG) comprising the representatives of the participant companies or teams is established.

5. Interface Control This group may be necessary because the large number of developers and organizations that may be participating in the design effort make it imperative to ensue compatibility of all interfacing entities and to establish better communication.

5. Interface Control In most cases, an ICWG is formed at the start of the project. It is composed of the interfacing developers and users and the prime developer's SCM activity. The SCM activity will identify all of the interface specifications and documents authorized by the ICWG, and when released by the ICWG, place them under SCM control.

5. Interface Control The change process for an interface document is the same as that of any other CI; the only exception is that the CCB is replaced by the ICWG [7]. The SCM activity will also maintain the status accounting of the documentation and changes and provide periodic reports to the various participating organizations represented on the ICWG.

5. Interface Control Tools are now in use that will map the entire software system, including interfaces, and delineate the changes that have occurred by some form of reference marking, such as version number or version letter. Such information can be acquired online (if SCM tools that capture this information are used) by the SCM activity and the project for immediate information.

7. Software Library The software library is the heart of SCM. It contains everything that is important to a software project: source code, user and system documentation, test data, support software, specifications, project plans, and derived items [8]. The software library must be secure. It must only be accessed in ways that are consistent with sound SCM. Both read access and write access must be controlled, the former to prevent unauthorized disclosure and the latter to prevent unauthorized or accidental change or deletion.

7. Software Library The software library is an important asset to the performance of the SCM process, especially in carrying out change control, release management, and status accounting activities. A software library is defined as a controlled collection of software and related documentation designed to aid in software development, use, or maintenance [1]. Types include development library, controlled library, and master library

7. Software Library The development library (sometimes called dynamic library) holds newly created or modified software entities, data units, or documentation. The dynamic library is the working library for the development of the source code and is usually managed by developers. This can be a collection of many independent libraries, each owned by different developers. The items in the dynamic library are not under configuration control.

7. Software Library The controlled library (sometimes called production library) is used to manage current baselines and control changes made to them. It maintains CI units promoted for integration. The controlled library is the entity for retention of approved or released CIs as well as the retention of approved and released software documentation that will be delivered to the customer or distributed to the marketplace.

7. Software Library

7. Software Library The master library (also known as static library) maintains archives of various baselines released for general use. This library contains master copies and authorized copies of software and documentation released for operational use. The items in the master library should not be changed under any circumstances.

7. Software Library The master library usually consists of many different physical repositories or storage media. The software repository is the entity that archives software and related documentation at the close of the project. All released documentation and software in the master library should be backed up. The working interfaces of the various software libraries are shown in Figure 11.1.

7. Software Library The status accounting activity will account for all of the software documentation and code in the various library segments and report their status at any given time, including the changes underway, approved, or incorporated.

8. Summary The principles of SCM revolve around three key components: version control, system building, and release management. Version control is simply the automated act of tracking the changes of a particular file over time. Version control gives the ability to trace the history of all CIs in a system and to recreate any previous version of a file.

8. Summary The system build produces the product that is given to clients or shipped to customers. Software release management encompasses the identification, packaging, and delivery of the elements of a product such as the executable, documentation, release notes, and configuration data.

8. Summary Two other important aspects of SCM are interface control and subcontractor control. Interface control is the process of identifying, documenting, and controlling all performance, functional, and physical attributes relevant to the interfacing of two or more products provided by one or more organizations.

8. Summary Subcontractor control is an activity in which the procedures for ensuring the quality and completeness of products and components of the system that are being developed by a subcontractor or bought directly from the market are established. Both interface control and subcontractor control procedures should be described in the SCM plan.