The Future of CM Systems

The Spectrum of Functionality Figure is intended to be a high-level snapshot of state of the art in CM features. Several "arms" in the spectrum indicate possibly different CM areas, but it is envisioned that, as experience in CM systems is gained, these "arms" will join. This means that there is probably a fundamental CM model that encapsulates all the functionality presented in the spectrum. Further analysis work is needed to validate this probability.
But regardless of whether every CM system designer is trying to implement the same features, there are political and technical issues that do affect the future of CM systems. (Political issues relate to marketing and standardization; technical issues concern the feasibility of implementing certain mechanisms.)
A major political issue concerns the evolution of Computer Aided Software Engineering (CASE) tools. For instance, should CASE tool vendors ignore CM within their tools and assume that environment vendors will provide the CM support in their frameworks? Or should CASE tools builders provide CM support in their tools? If CASE vendors incorporate their own CM support, users will have to solve the problem of integrating different CM systems when they install their (different) CASE tools. Also, from the vendors' viewpoint, will they essentially be duplicating much of the work that has already been done or is now being attempted for environment frameworks?
On the other hand, if CASE vendors do not incorporate CM into their tools, can they rely on environment architects to provide a suitable framework to integrate CASE tools and simultaneously provide some sort of global CM capability? The answers to these questions are not known. In either case, there is the implication that some kind of standardization would probably be needed for CM systems in relation to environments, or vice versa.
Many technical research issues will affect the capabilities of CM systems. They include:
What is the appropriate technology on which to base a CM system? Is an object-oriented database with persistency notions for immutable objects the most suitable?
In what layer of an environment's architecture does CM fit? Should it be at the base level in the database, making it an integral part of an environment framework? Or is it all a matter of specifying CM as a process at a higher level in the architecture?
Can the mechanisms for CM be separated from all the CM functionality, that is, are there "standard" CM primitives that could be used in any environment to support all the CM functionality? Is there a common CM model?
Is it possible to provide distributed CM support? Can geographically dispersed software teams use the same CM system for local CM and for system integration? This is a major problem in industry, particularly for Department of Defense contractors.
Is it possible to support cross-development of software? Can engineers developing a product on a host machine easily move it to the target machine, while still maintaining CM control over the product?
Is scale a limiting factor for CM systems? Is the CM support for a million line product the same as that for a 100 million line product?
Is it possible to model all aspects of the CM process, including the peopleintensive parts, into a CM system?
Answers to the above questions are not yet obvious. It is likely that progress will come from various sources from CM system vendors, environment architects, tool integrators, the software process modeling forum, and particularly from the computer-aided design/engineering (CAD/CAE) and computer-integrated manufacturing (CIM) worlds.

Team Features in CM Functionality

Workspace:
The shape System combines the notions of a repository, system model, configuration thread and object pool, and adds the notion of a workspace. Workspaces pertain to each user and are designed to prevent users from interfering with one another's work. The user designates a workspace and imports files from the central repository. The workspace is intended to represent a certain status of a configuration (i.e., a certain version of part of the product). All work such as editing and compiling can be done in that workspace without affecting anything being done by other users in their workspaces. All by-products of the work remain in the workspace without affecting the central repository. When the user is finished with changes to a configuration, it is exported back into the central repository (after being approved).
The workspace is more than just a directory since version control capabilities are provided within the workspace, rather than just at the global level of the public repository. Also, only the user or designated users associated with that workspace can access it. A configuration can be accessed only from within a workspace, rather than from any directory. The CM system provides a team with more prudent access to parts of the products and prevents them from accidentally interfering with each other.

Transparent View:
The Software Management System (SMS) enhances the notion of a workspace with a transparent view repository.
This means that only the versions of the files in which the user is interested will be seen in the workspace; that is, version selection occurs transparently. All other versions are hidden from view (although they physically exist). The workspace then gives the appearance of a specialized repository for the user. Files that are checked out from the main repository are checked out to the workspace, and users are assigned access to that workspace. Files in the workspace effectively belong to that workspace instead of to a user.
A history of all the changes made in the workspace is captured. The user can take a snapshot of versions of the files local to that workspace. Naming of files is local to the workspace rather than globally unique. The transparent view acts as a local repository and as a protection mechanism against information overload and unauthorized access to non- local versions of files.

Transaction:
The transaction notion of NSE is an enhancement of the workspace and transparent view notions. It can represent a unit of work and supports: isolation of work between users; interactions between users; merging of changes based on the structure of the product.
The transaction consists of an environment and a set of commands. A transparent view and workspace is provided by the environment. Commands between environments provide the interactions. The commands represent a protocol used to coordinate the actions between users and to represent the communication of the actual changes.
Users work independently in their environments, changing the same or different parts of the product. The engineer can update the repository with a new version of a file changed in the environment. NSE assists in merging the changes into the repository. But it checks that what exists currently in the repository (which could have been placed there by some other engineer) does not conflict with the new changes coming.
If there is a conflict, NSE notifies the engineer about the merging problems and provides assistance in eliminating the conflicts.
Just as users can update a repository by merging changes from the workspace into it, users can request that any changes made by another user (who has already updated the repository) be incorporated into the users' local workspaces. Thus, the transaction supports teams changing the same or related parts of the product.

Structure and Construction Features in CM Functionality

Change Set:
The Aide-De-Camp (ADC) system takes one of the basic mechanisms of a file repository with version control and makes it accessible to the user for supporting the easy creation of a particular version of a product (or part thereof).
It does this by extending the notion of a delta. The delta is given a name and the user defines a formula that indicates which deltas should be combined to make up a particular version of a file or part of the product.
The combination of the deltas and the files to which they are applied and the reasons for each delta make up the change set. That is, the user can designate a change set that represents all the changes to a group of files (such as a configuration) and the reasons for each change (which could be the same across the whole group); ADC keeps track as to which delta is associated with which file in the group.
The user can then treat this group as a whole and perform operations on the group. At any time, the user can create a version of a product by defining a base version plus a combination of change sets. The change sets reflect an audit trail of changes to a configuration of files as well as a means of accessing any version of a configuration that is not dependent on the latest version of that configuration.

System Model:
The Cedar System Modeller was one of the first systems to explicitly define the structure of a configuration, i.e., a set of related components that make up the product under development. The System Modeller tracks the changes to components and controls the compiling and loading of configurations. The system model makes it clear to the environment what components are relevant and what relationships they have.
It has a readable textual representation that can be edited by a user at any time and can be used by tools such as browsers, debuggers, and inter-module analyzers. In fact, the environment can use this model to perform some analysis on the components and make sure that the product is in a sensible state.
For instance, a user changing a file may invalidate several other related files. The System Modeller recognizes this automatically and can automatically recompile the related (out-of-date) files, thereby creating a new latest version of the product. By defining the static structure of a product, the System Modeller allows the environment to assist in maintaining the integrity of the product.

Sub Systems:
The Rational environment adds to the notion of a system model and repository by incorporating features for dealing with a very large product.
Rational provides for partitioning a large Ada product into parts, allowing for confining the scope of the effects of changes. The parts are called subsystems. Subsystems have interface specifications and represent a configuration item; therefore, they can be treated as a whole.
Engineers can work on a subsystem making changes and as long as none of the interface specification is changed, any recompilations will happen only to components within that subsystem. Changes to the interface will possibly require the whole product to be recompiled.
Subsystems have version control on their components, and subsystems themselves can be of a particular version. Subsystems thus minimize the need for recompiling the complete product. Also, due to the interface specification, the user can mix-and-match subsystems to make up a particular version of the product. The Rational environment checks that only compatible versions of subsystems are combined. Subsystems represent a way for having users limit the scope of their changes and for the environment to check the validity of combined configurations.

Configuration Thread:
The Domain Software Engineering Environment (DSEE) takes the notion of a system model and enhances it by incorporating derived objects (i.e., object files as well as source files) and tools that do the derivation to the model.
This allows the user to capture more precisely the static components involved in building a product. These components include: the versions of tools, the parameters used to invoke the tools, and the versions of components, along with other specific parameters that are worthwhile recording.
As the product is compiled, DSEE automatically captures all the time and the versions of the components used and keeps this information in the repository in an object known as the configuration thread. Each configuration thread is given a unique identifier by DSEE. This identifier can then be used by DSEE as the permanent, all-encompassing history of the components necessary to build the product.
At any point in time, the user can simply request that a particular version of the product be regenerated. Users no longer need to keep multiple copies of the same version of files and tools and any intermediate files in some central location: DSEE has a complete inventory of all components, their versions and their timestamps, thereby reducing the need for multiple copies and, hence, wasted space. Much of the management of derived objects as well as source objects is under the control of the CM system.

Object Pool:
Using its notions of system model and configuration thread, DSEE has all the necessary information to recognize what is required to generate a particular version of a derived object.
By associating this information with each derived object, all the objects can be put into a pool. Thus, whenever a user needs a particular derived object (or a compatible one), DSEE can automatically check whether one already exists in the pool, thereby obviating the need for regenerating the object.
The user need not know that that derived object exists: DSEE does all the checking based on both the generation information the user gives and on existing configuration threads. This saves on the amount of compiling time and space required, and reuses work already done. In effect, the CM system has knowledge of how to optimally and exactly regenerate a particular version of the product.

Attributes:
The Adele System generalizes upon the repository, system model and configuration thread notions by using a database and data modeling capabilities. Thus the repository becomes more object oriented and the user can describe a product in terms of a data model.
Essentially, the components of a product are represented as database objects with attributes and relationships. Attributes are user-defined information about an object, for example, a certain object is a debugging object and its target system is VMS.
Relationships define dependencies between objects, such as object A depends on object B. Hence, the user can describe a configuration in terms of characteristics of objects, rather than in terms of a composition of specific versions of objects. That is, by using selection rules and constraints centered around the attributes, the system can compose an appropriate configuration.
The user can define any structure to a product (rather than just a hierarchical structure) and can designate a product in terms of desired characteristics. Thus, the user can describe a product at a higher level of abstraction (instead of in terms of a long list of instances of files).

Consistency Checking:
The Configuration Management Assistant (CMA) enhances data modeling for CM with the addition of certain classes of attributes and relationships. Based on the meaning of the attributes and relationships, CMA can check to determine whether a configuration (which is a set of instances of objects) is valid.
To be valid means that all the objects in the configuration make up a workable set; they are consistent with each other. It is the semantics of the attributes and relationships that permits CMA to determine the consistency. The classes of attributes represent user-defined characteristics including constraints, typing, and versions of configurations. Classes of relationships represent logical dependency, consistency, compatibility, component, instance, and inheritable dependency.
These allow CMA to ensure that all instances of objects have compatible attributes and relationships in the formation of a configuration. In particular, CMA checks to determine whether configurations are complete, consistent, unambiguous, and have no version skews. With the formation of a configuration, CMA can add that configuration's characteristics to its database. Then, for subsequent use of that configuration or parts of it, CMA has enough information to check their consistency. The user can rely on the system to identify any inconsistencies and to preserve consistencies in creating and re-using configurations.

Process Features in CM Functionality

Domain:
PowerFrame is a system designed for the computer-aided engineering/design (CAE/CAD) field and essentially shields its user from any notion of a file system and configuration management.
Users see only their domain-specific world and any CM is transparent to them. All they may see includes the appropriate tools for a particular task, and certain forms of presentation such as a logic-schema or a layout design, data that are pertinent to a particular task, and the form of commands that are pertinent to that domain. The user does not have to worry about such tasks as version control or relationships between files, since the system handles that behind the scenes. The users' working setup looks just like their domain's working environment.
In effect, the CM features are hidden under the guise of domain-specific concepts.

Life Cycle Phase:
The Change and Configuration Control (CCC) system provides some notions for supporting a particular lifecycle model in the sense of supporting phases in the lifecycle. In particular, CCC separates out development, product testing and releasing a product. This separation allows different kinds of users such as software engineers and testers to work on apparently the same code at the same time. This is achieved by passing the code through to separate directories that represent each phase. Work can continue independently in each directory, but, in essence, progresses from phase to phase, from person to person. As the independent work is completed, all changes are merged into a final product in the repository, tested and approved. A new release can be created and the cycle can begin again. In effect, the lifecycle model is achieved via parallel activities on versions of configurations.

Change Requests:
In CCC, a change-request is a documented request to make a change and is presented as an on-line form with fill-in-the-blank screen panels. The request is for changes to be made to a section of code or to many related parts of the product such as a configuration.
The scope of the change is user-defined, but CCC keeps a record of the request and what is affected by the change. The request is assigned a unique name. Once the form is completed with details of all ramifications (such as which components will be affected), the form can be electronically mailed to the CM manager who can mail back an approval or rejection to the software engineer. If approved, engineers are assigned to make the change, and those engineers are given access to the repository based on the change request assignment.
The change request is resolved by making the changes. Once the changes are tested and approved, the affected components can then be passed to the approved configuration. Change requests provide a history of all changes to the repository, a status report for changes in progress, and an audit trail of changes done and changes rejected.

Contracts:
The ISTAR environment provides for modeling some parts of a software development process. It models information flow and the completion of tasks. It does this via contracts. Contracts incorporate information flow, roles, tasks and components of the product and are "exchanged". A contract is fulfilled by the "passing" of a particular version of the product (or part thereof). The components are passed to certain elements of the process model such as a person or, logically, to a new phase, that is, the repository of part of the product is passed on.

Component Features in CM Functionality

Repository:
(from Spectrum of Functionality in Configuration Management Systems)
RCS provides the notion of a repository for source code ASCII files. In effect, the repository is a centralized library of files and provides version control. Most CM systems use some kind of notion of a repository. Any component in the repository is considered to be under a form of CM. All the CM information about files and the content of the files are kept in the repository. Hence, any CM controls pertain to what is in the repository. Users access the repository to glean information about the files.
To work on the file, users withdraw (that is, check out) a particular file into their working directory, perform any work on the file, and, at any point in time, replace it in the repository (that is, check it back in). Replacing the file means creating a new version of that file. A version number is automatically associated with each replaced file; consequently, users can withdraw any file with a particular version number at any time. So that users cannot simultaneously withdraw the same file and work on it, once the file is withdrawn, it is automatically locked until it is replaced.
The repository stores file history information which includes the different versions of the files, the reason for a change, who replaced that version of the file and when. Note that the complete code for the different versions is not stored. Rather, only the actual difference between each version is stored; this is known as the delta. This assists in space savings and access time to a particular version.

Distributed Components:
(from Spectrum of Functionality in Configuration Management Systems)
DMS provides a repository that controls files distributed on different hardware platforms. The repository is centralized, but the data from the repository can be distributed. DMS is aware of the distribution and carries out its CM taking that into account, such as by providing some fault tolerance facilities along with the necessary translations of file formats. So, to the users, the distribution is transparent. Users carry out their work on the repository as though all the files were located on their own workstations. When they are ready to return the changed files to the main repository, they use the DMS facilities.
A team of users geographically dispersed can be working on the same configuration of files. Multiple copies of files can exist on different workstations. Any changes to files in the repository can result in the local copy on the distributed workstations being updated since the system knows where all the local copies are. In effect, distributed users have access to a centralized repository, and to them the CM facilities seem to span the network of heterogeneous workstations.

Spectrum of Functionality in CM Systems

The functionality areas of interest for the CM system features to be discussed concern component, process, team, and a combination of structure and construction features. The following sections discuss each feature in a simplified manner.

The final figure gives a summary of all the features and systems discussed. Note that the description of features is simplified in order to focus on a certain aspect. It is realized that this may not highlight the full capabilities of features nor of systems. But, for the sake of presenting a spectrum, simplification is used since most CM systems tend to overload the purpose of various features.

Component Features:

In particular, Revision Control System (RCS) provides a classic file repository feature and Design Management System (DMS) extends that notion by catering to distributed components.

The Process Features:

The CM systems are Change and Configuration Control (CCC) ,PowerFrame and ISTAR. The features are are an extension of the repository feature of a system such as RCS.

The Structure and Construction Features:

The systems are:

Aide-De-Camp (ADC)

Cedar

Rational

Domain Software Engineering Environment (DSEE)

Adele

Configuration Management Assistant (CMA)

Team Features:

Shape

Software Management System(SMS)

Network Software Environment (NSE)

All teh subsections will be described in upcoming articles.

SCM Interaction with Verification and Validation

SCM is most important, and most often neglected, during V&V activities, which include software testing. It is employed in tracking which module versions are included in a particular system build, as well as which tests have been run. The results of the tests are tied directly to the modules or subcomponents being tested. Many times there are "action items" resulting from the tests. SCM tracks the action item status, so overall system status can be assessed well before final builds and releases are done.
Verification and validation testing are supported through the four basic SCM processes: identification, control, auditing, and status accounting. Let's look at examples of V&V testing in the context of each of these components.

SCM Identification Benefits to V&V
Automatic preparation of release notes
List of changed software modules
Definition of development baseline
Generation of incident reports
Definition of operational baseline
Control of the configuration item identification
Management of CCB meetings
Prioritization of test and incident issues
Establishment of turnover dates
Approval of audit and test reports
Approval of incident report resolutions

SCM Auditing Benefits to V&V
Comparison of new baseline to previous baseline
Assurance that standards have been met
Audit trail of the testing process (verification, validation, and acceptance) of the software system
Documentation of experience with technical aspects of system engineering or software engineering

SCM Status Accounting Benefits to V&V
Logging and tracking of incident reports
Publication of CCB minutes

With all of these potential benefits of SCM, project managers must address real-world considerations. Management commitment is the real key to implementing SCM on a specific project in a given organization. By treating the implementation of SCM as a project, the project plan must start at the top to secure commitment to checks and balances. Now is the time to bring out the organization's list of project disasters to draw on management experience with their previous software project difficulties. If there are no historic disasters in the organization, or if it is inappropriate to discuss them, refer to literature articles that provide accounts of project disasters (refer to the Web resources at the end of this chapter). Finally, after putting a notional return-on-investment financial argument in place, explain the intangible benefits of SCM.
One of the major sources intangible benefits is auditing. Auditing can be a heavy consumer of configuration management resources, and management may question the benefit of this kind of expenditure. Auditing pays for itself through the avoidance of larger, unnecessary expenses. Savings of 100:1 (large projects) or 4–6:1 (small projects) are obtained by finding and fixing problems early in the life cycle. The auditing process in SCM uncovers the areas where a little more effort or control will result in higher-quality software products and lower overall project costs.
There can be audit compromises to reduce costs. As a project manager, plan audits based on both the phases of the life cycle and the frequency of builds, versions, releases, and product families. Auditing each baseline in a project while reducing the depth of each audit maintains some traceability with loss of visibility.
Eliminating one or more audits (installation baseline, for example) maintains visibility but slightly impacts traceability.

Some Problems with Software

Software development has traditionally suffered from producing end products with a definite lack of inherent quality. The symptoms of this quality lack are listed here:

Software development projects are often delivered late and over budget.
Often the delivered product does not meet customer requirements and is never used.
Software products simply do not work right.

As we look into the symptoms of our software development malaise, five principal issues related to software development arise.

Lack of Visibility
Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, it is not easy to look at software and assess how close it is to completion. Without strong project management, "software is 90% complete 90% of the time." Through the adoption of SCM policy and the definition of the configuration management model of the software under development, all CIs, components, and subcomponents are immediately visible for versions, releases, and product families.

Lack of Control
Because software is inherently intangible, it is also more difficult to control. Without an accurate assessment of progress, schedules slip and budgets are overrun. It is hard to assess what has been accomplished and what remains to be done. SCM provides the mechanism for controlling the project through measuring the amount of effort compared to the project management plan and estimating the future effort based on past work.

Lack of Traceability
A lack of linkage between project events contributes to project failures. The main benefit of SCM is providing the traceability among versions, releases, and product families. The value of this traceability is enormous when a problem arises in one release or product family that impacts other client releases and products. Making one change and promoting that through the entire product software base is an incredible cost savings in time, money, and client good will. A lack of linkage between project events contributes to project failures where solving one problem either exacerbates a problem in another area or fails to fix the same problem elsewhere. A traceability thread allows management to examine the chain of events that caused a project to encounter difficulty as an integral process within the auditing capability of SCM. A project becomes a year late one day at a time unless the effort reported on the schedule maps to the actual work being done and traced within the software configuration management system.

Lack of Monitoring
Without traceability and visibility, monitoring of software development projects becomes extremely difficult. Management cannot make informed decisions, and thus schedules slip further and costs continue to exceed budget.
There is no way to monitor a project when the project manager has no tools to look into the actual product development within the project. SCM provides the tools that open up the process to external monitoring. With SCM in place and a policy of traceability and visibility accepted, monitoring of software development projects becomes a simple part of the overall project management task. Management makes informed decisions avoiding schedule slips and budget excesses through the monitoring available with SCM tools and the integral workings of the CCB.

Uncontrolled Change
Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it. People would rarely ask a bridge constructor to make the kinds of changes midproject that software customers tend to request. The impact of such changes can be just as great. All SCM tools, along with the CCB, support a mechanism for appropriate change control.

Benefits of SCM Process and Tools

SCM benefits an organization in four areas: control, management, cost savings, and quality as shown above. These four benefits are mapped to an organization's overall goals and objectives when the decisions are made to bring a SCM tool in-house. The features of a SCM tool further support these benefits.

Control
Control in SCM provides the ability to review, approve, and incorporate changes into a configuration item. There must be one controlling SCM tool so that there is only one set of training, license management, installation, and user procedures. All project personnel use the tool. Inherent in the tool is a standardized, measurable process for change. Integrity maintenance of CIs is enforced throughout the product life cycle. The tool permits only controlled change to the baseline CIs, and all changes are tracked.

Management
Management in SCM is concerned with the automation of identifying and guiding configuration items through their life cycle to final assembly as part of product and delivery. Identification of CIs through a unique naming convention allows version, release, update, and full change tracking. Baselining of CIs with the ability to produce product deltas from the baseline satisfies requirement and schedule changes along with product family support. Rapid reviews and audits of CIs are accomplished through the analysis of historic information collected. Project status reporting is accomplished in a clear and consistent format based on SCM collected information on all CIs under configuration management.

Cost Savings
Cost savings are realized across the entire product development life cycle with SCM. Maintaining product integrity through defined, tracked, and audited CIs provides a managed bill of materials for the product released to customers. Cost savings scale with SCM use and application across applications. This scaling is dependent on the depth of control needed for each application product release tree. Deep combinations for product families can be analyzed for risk exposure and cost savings directly impacted by the amount of configuration management applied. Side effects are reduced through controlled change by understanding the impact on all versions and releases. Accurate and repeatable release control is produced in a repeatable fashion over entire product families for all customers and users.

Quality
Software development is a people-intensive activity, and quality must be considered at every person-to-tool interface. Ensuring a high-quality work environment must address the process of building software products in an automated fashion. This must include tracking CIs to the tools that produced them and the clients that ultimately receive the product. Measuring the end product to ensure high quality is done through tracking the changes made to a product throughout its life cycle. Repeatable management and change control in a documented and measured fashion allows accurate estimation of future efforts. Quality is an ongoing process. The lessons learned in one product must be transferred to new, related products and entire product families.

SCM Tools

The minimum features for SCM tools are closely related to the task of handling the different product deliverables produced within the project software engineering process. Tool requirements and selection criteria are based on a series of features that provide a consistent look and feel with state-of-the-art software development environments. An SCM tool must have multiuser support, an intuitive graphical user interface, conformity to the organization's development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, and management of nondevelopment objects.

Basic selection criteria includes the following:

Multiuser support—Tools are to be used concurrently by several users. They have to store all acquired information in a central, shared repository, and the SCM tool has to allow controlled parallel work on the different project documents.

Intuitive GUI—Because the tools will be used throughout the project and not only by developers, an intuitive, easy-to-use graphical user interface is considered very important.

Conformity to the organization's development environment—The organization must define up front the hardware and software development platforms used. For example, the project may work on a heterogeneous network of Unix-based workstations (mainly Sun Sparc stations) and PCs. The workstations may be used for some part of the development and as a file server and communication server. The PCs may be using MS Windows 2000 NT. PCs and workstations may be interconnected using the NFS protocol (especially Sun PC-NFSpro on the PCs). The tool has to be able to store its shared repositories on a workstation and has to allow PC clients as well as workstation clients supporting the operating systems and protocols.

Scalability—The tool should work equally well for smaller projects as for larger ones.

Flexibility in integrating other software development tools—The tool must allow the integration of all the other development tools to provide a highly homogeneous environment. Especially the tools for design, implementation, and testing will have to co-operate on the common SCM repository.

Ease of setup—The SCM tool should allow an easy installation and setup, and should be able to run nearly "out of the box." It should contain predefined, immediately usable models describing the types of items, the life cycle, and the roles of the different users. The importance of existing projects and their directory structures should be made as easy as possible.

Modifiable models—Though a working set of models should be predefined, each of these should be modifiable and extensible. This is especially important because project managers and developers want to adapt these models to the software development process as defined for the company. Role models must be adapted to the roles assigned to the different employees on the project. Object-type models must be extensible to reflect different types of objects used in the environment and especially with respect to nondevelopment objects.

Process management—Process management comprises efficient support of object life cycles and object promotion, together with a flexible and extensible approach to life cycle models. Based on a concept of object types, it should be possible to attach different life cycles to different types of objects.

Extensive support for the development phase—During development when checkout and update of objects is frequent, the tool should aid a developer in determining the set of objects that need an update or renewed check-in. Although this requirement seems to be trivial at first, the latest version of the tool you plan to use must be evaluated with emphasis on the environment prior to the first build. These do a good job in change management once the first release has been produced.

Management of nondevelopment objects—SCM tools must manage all artifacts of the project, not just code. These will mainly be documents and their versions and releases. The tool must be able to support that.

Permission management—Everyone should not have access to make changes to different pieces of the software. In many situations, check-in and checkout only will not prevent integration from being broken by multiple people modifying code for their own designs and interfaces.

The keys to any tool selection are to know your project's tool requirements, to understand how tools relate to the project's success factors, and to do a current market search for tools.

SCM Staffing

On any given project, a few engineers or developers specialize in and become your SCM experts. While they are the gurus, everyone on your project will be a user of the product that they select, develop, and maintain. It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product.
We can group the characteristics and abilities needed by the four SCM functions: identification, control, auditing, and status accounting.

Identification
Ability to see partitions
Ability to see relationships
Some technical ability
System engineering orientation
Programming

Control
Ability to evaluate benefits versus cost
System viewpoint (balance of technical/managerial, user/buyer/seller)
An appreciation of what is involved in engineering a software change

Auditing
Extreme attention to detail
Ability to see congruence
Ability to perceive what is missing
Extensive experience with technical aspects of system engineering or software engineering

Status Accounting
Ability to take notes and record data
Ability to organize data
Some technical familiarity
System engineering orientation
Programming

Once the staffing of the SCM function is complete and the overall organization's SCM policy is established, the configuration control board (CCB) is identified. The CCB is the heart of the control function. It infuses sustained visibility into the process of change throughout the system life cycle and traceability into the process of change. The membership in the CCB is not limited to the developers or product line management. All stakeholders in the product must be represented. This includes the end-user usually represented by marketing, subcontractors used in the product development, product development funders, and the product developers. The CCB is the final decision maker as to what bug fixes, enhancements, and feature sets get included in the next product release.

The CCB has periodic meetings, with the results documented. These meetings can be done in a rapid fashion, and doing them online or via email is an adequate way to gain consensus and come to a decision. Important to status accounting is the documentation of CCB meeting minutes. The basic purpose of the minutes is to provide the CCB decision makers with the information needed to make intelligent, informed decisions. The amount of detail varies with the meeting frequency and technical content.

Potential SCM Problem Classes

When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified.

Multiple developer syndrome—When you have a project that requires more than one developer, there is the problem with multiple people working on one product base. This could be a test plan, requirements specification, or code. Effort is wasted when two or more people work on the same file and then save it. Without SCM control, the last person to save the file has those changes saved. All the other changes are lost. The simplistic method of locking a file while one person reads it prevents others from simultaneously working on the file.

Multiple releases—Enhancements to the base product should result in additional releases of the product containing the latest changes. Once the second release is available, some users are on an earlier release. Having an SCM makes managing those releases possible. When bugs are reported, changes must be made across all impacted releases. As new features become available in the product, they must be made available to all current users, no matter what the release date.

Product family—As products are built that offer the same capabilities across a heterogeneous set of hardware platforms, both the common and the platform-specific software bases must be managed. If a product operates on four versions of Windows, three versions of Unix, Red Hat Linux, and FreeBSD the user manual may be significantly the same. But there is a different installation process for all nine platforms. Without SCM, nine individual manuals must be written and maintained. With SCM, one documentation configuration item with nine versions will suffice, with the differences being only the installation procedure.

Requirements change—The first law of systems engineering is that no matter where we are in the system life cycle, the system/software will change, and the desire to change it will persist throughout the life cycle. Dealing with this change represents a major management challenge. Having an SCM in place will ease the management of these changes to the requirements of the products that will occur. An SCM allows the easy identification of feature sets that group the requirements satisfied by a release or version of the product. These feature sets are tracked through development to delivery.

Schedule change—As requirements change, so must the schedule. Mapping the feature sets for release to the schedule allows project managers to more accurately estimate the effort required for generating that next release. Having the SCM in place allows the project manager to look at historic effort levels in getting out releases. This is an enormous aid in estimating the "what if" scenarios that result from taking on new product users or providing customized solutions to other clients.

Software changes—No product developer has the luxury to write code once and forget about it. Along with requirements and schedules, the software being developed changes in response to those other changes. Software is not static. That is its inherent power. It can be changed, so it will be changed. SCM systems track those changes so that, if the wrong change is made, a previous working version is available. This capability alone has saved enormous amounts of time as developers have tried out specific solutions that did not work in the product environment and were able to rapidly back up to a working version.

Staff changes—In the best of organizations, people get promoted, take other jobs, and leave. When that happens in the midst of a development project, not just the technology knowledge goes out the door. The long-learned knowledge of how things are done is also gone. So when a replacement person is brought on board, they may know the technology, but without a documented SCM process, they will have no real idea how to do product development. SCM provides the framework and knowledge base of what has gone on before in the project. A new staff member has one place to go to understand the "how" of the organization's development process and the "what" of the project to date.

System/user documentation change—No product developer has the luxury to produce in a technology or tool vacuum. All product developers use hardware microcode, operating systems, tools, and documentation that are not under their control. When a major operating system change occurs (e.g., the next "best" release of Windows), an SCM will allow tracing all the CIs, components, and subcomponents that are impacted by that change. The change is isolated, and the amount of effort required to respond to the change can be estimated. This provides a responsible schedule for an upgrade based on situations beyond the organization's control.

Four Basic Requirements for SCM System

Identification, control, audit, and status accounting are the four basic requirements for a software configuration management system. These requirements must be satisfied regardless of the amount of automation within the SCM process. All four may be satisfied by an SCM tool, a tool set, or a combination of automated and manual procedures.

Identification—Each software part is labeled so that it can be identified. Furthermore, there will be different versions of the software parts as they evolve over time, so a version or revision number will be associated with the part. The key is to be able to identify any and all artifacts that compose a released configuration item. Think of this as a bill of materials for all the components in your automobile. When the manufacturer realizes that there has been a problem with parking brakes purchased from a subcontractor, it needs to know all the automobile models using that version of the parking brake. It is the same with software. If we are building a multimedia system that has audio MPEG3 drivers for Windows 98, Windows 2000, Windows CE, Linux, and FreeBSD operating systems, how do we find out which releases are impacted when we find an error in the Linux product? You must go back to your SCM system to identify all the common components in all operating system releases that are impacted.

Control—In the context of configuration management, "control" means that proposed changes to a CI are reviewed and, if approved, incorporated into the software configuration. The goal is to make informed decisions and to acknowledge the repercussions associated with a change to the system. These changes may impact budgets, schedules, and associated changes to other components. If a problem is reported in a released product, software engineers must act quickly to evaluate repercussions—a "fix" for one client's version of the product may be dangerous to another. The control inherent in an SCM system shows each version in which the flawed component appears.

Auditing—Auditing an SCM system means that approved requested changes have indeed been implemented. The audits allow managers to determine whether software evolution is proceeding both logically and in conformance with requirements for the software. The SCM system should document changes, versions, and release information for all components of each configuration item. When such documentation is in place, auditing becomes a straightforward analysis task.

Status accounting—Reports and documentation produced by the status accounting function are the auditable entries. All approved parts of a software configuration must be accounted for, and the software parts list must reflect the transition from part CIn to CIn+1. This accounting provides the historic information to determine both what happened and when on the software project. Status accounting enables the auditing requirement of the SCM. As a project manager, the status accounting holds a wealth of information on the amount of effort required throughout the life cycle of the product in its development and maintenance. This is critical to the software project manager in making estimates for new systems based on historic information. The SCM can be used as one of the key components of the project managers' metrics system.

SCM Principles

SCM can be viewed as a pyramid, as shown in the above figure.Let's explore each of the six layers, starting at the bottom and working to the top.

Understanding of SCM:
An understanding of SCM is critical to the organization attempting to institute any system of product control. Understanding through training is a key initial goal, as shown in the pyramid. Executives and management must understand both the benefits and the cost of SCM to provide the needed support in its implementation. Software developers must understand the basics of SCM because they are required to use the tool in building their software products. Without a total understanding, a partial implementation of SCM with workarounds and back doors will result in disaster for an SCM system.

SCM Plans and Policies:
Development of an SCM policy for an organization and the subsequent plans for each product developed is crucial to successful SCM implementation. Putting SCM into an organization is a project like any other, requiring resources of time and money. There will be specific deliverables and a timeline against which to perform. The policy for the organization lays out in a clear, concise fashion the expectations that the organizational leadership has for its system. It must lay out the anticipated benefits and the method to measure the performance to those benefits.

SCM Processes:
The specific processes of SCM are documented for all users to recognize. Not all SCM processes need to be used within an organization or on a product. Yet, it is important to have available, in "plain sight," those processes that are used specifically in your organization. This also maps those processes to how they are implemented.

Metrics:
The measures used to show conformance to policy and product plans are important details. These measures show where the organization is along the path to reaping the benefits of SCM.

Tools for SCM :
The tools used to implement SCM are the next-to-last item on the pyramid. For too many managers, this is often the first instead of the fifth stem in SCM—many organizations and projects simply buy a tool, plop it in place, and expect magic. Actually, it makes little sense to pick the tools to use in SCM without having done all the previous work. Putting a tool in place without training, policy, or metrics is an exercise in automating chaos. You will simply have an automated way to turn out the wrong product faster

SCM Configuration Items:
The configuration items (CI) are those "things" that represent internal and external project deliverables. They are the final result of all the work done to implement SCM in your organization.
Along one face of the SCM pyramid is the training plan and its execution. A common management mistake is to arbitrarily drop an SCM requirement on a development organization without a corresponding investment in training. The process of SCM and the tools used in its instantiation are complex in concept and execution, making training a true requirement.
Along another face of the pyramid, we indicate the transition plan to get to an effective SCM implementation. The introduction of configuration management is a project in and of itself, requiring a project plan within the context of the organization. Just like planning for development, plans for improving product quality and reducing development time must be followed to reap the benefits.

SCM is the identification scheme for the software components of a system. It controls changes to the configuration and maintains integrity and traceability of the configuration. Software in this context refers to all deliverables: documentation, test scripts, test data files, code, and so on. Change control is the management of change as one part of the SCM process. Version control is the management of the product versions generated as part of the SCM process. Release control is the transformation of configuration items into a deliverable product. A configuration item (CI) is a standalone part of the product development that is combined with other CIs into a release. Examples of software CIs include design documents, manuals and tutorials, measurement data, program trouble reports, requirements, source code, and test cases.

SCM Is an SEI CMM Level 2 Key Process Area:
At CMM Level 2, an organization moves beyond just getting the job done and into an environment where a software project management process is in place, the organization sets expectations via policies, and projects have disciplined phases and milestones. This level is described as the repeatable level, built upon key process areas of requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management. The goals for SCM at maturity Level 2 are:
Software configuration management activities are planned.
Selected software work products are identified, controlled, and available.
Changes to identified software work products are controlled.
Affected groups and individuals are informed of the status and content of software baselines.
Questions that assessors might ask include:
Is a mechanism used for controlling changes to the software requirements?
Is a mechanism used for controlling changes to the software design?
Is a mechanism used for controlling changes to the code?
Is a mechanism used for configuration management of the software tools used in the development process?

Software Configuration Management

Software engineers usually find coding to be the most satisfying aspect of their job. This is easy to understand because programming is a challenging, creative activity requiring extensive technical skills. It can mean getting to "play" with state-of-the-art tools, and it provides almost instant gratification in the form of immediate feedback. Programming is the development task that most readily comes to mind when the profession of software engineering is mentioned.
That said, seasoned engineers and project managers realize that programmers are part of a larger team. All of the integral tasks, such as quality assurance and verification and validation, are behind-the-scenes activities necessary to turn standalone software into a useful and usable commodity. Software configuration management (SCM) falls into this category—it can't achieve star status, like the latest "killer app," but it is essential to project success. The smart software project manager highly values the individuals and tools that provide this service.

What Is Software Configuration Management?
Software configuration management (SCM) is the organization of the components of a software system so that they fit together in a working order, never out of synch with each other. Those who have studied the best way to manage the configuration of software parts have more elegant responses.
Roger Pressman says that SCM 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 different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made."
We think that Pressman's description is a better description because we often view SCM as meaning software change management.
Wayne Babich describes SCM as "the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes."
The Software Engineering Institute says that it is necessary to establish and maintain the integrity of the products of the software project throughout the software life cycle. Activities necessary to accomplish this include identifying configuration items/units, systematically controlling changes, and maintaining the integrity and the traceability of the configuration throughout the software life cycle.
Military standards view configuration as the functional and/or physical characteristics of hardware/software as set forth in technical documentation and archives in a product. In identifying the items that need to be configured, we must remember that all project artifacts are candidates—documents, graphical models, prototypes, code, and any internal or external deliverable that can undergo change. In SW PM terminology, a configuration item might be a proposal/estimate or bid, project plan, risk management plan, quality assurance plan, CM plan itself, test plan, system requirements specification, system design document, review metric, code, test result, tool (editors, compilers, CASE), and so on. There are basic objects and aggregate objects to be configured. The number of relationships among them reflects the complexity of the configuration task.

Why Is SCM Important?
Software project managers pay attention to the planning and execution of configuration management, an integral task, because it facilitates the ability to communicate status of documents and code as well as changes that have been made to them. High-quality released software has been tested and used, making it a reusable asset and saving development costs. Reused components aren't free, though—they require integration into new products, a difficult task without knowing exactly what they are and where they are.
CM enhances the ability to provide maintenance support necessary once the software is deployed. If software didn't change, maintenance wouldn't exist. Of course, changes do occur. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision.
CM works for the project and the organization in other ways as well. It helps to eliminate confusion, chaos, double maintenance, the shared data problem, and the simultaneous update problem, etc.

Who Is Involved in SCM?
Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation.

How Can Software Configuration Be Implemented in Your Organization?
We used to say, "Make a plan and stick with it—never waffle," and "Requirements must be frozen—how else will we know what to code?" Now, we say, "Plans are living documents—they will be in a continual state of change as project knowledge increases." We now know that requirements are never frozen—they merge, morph, and evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change.
Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. I will cover the issues and basics for a sound software project CM system in teh upcoming articles, including these:
SCM principles
The four basic requirements for an SCM system
Planning and organizing for SCM
SCM tools
Benefits of SCM
Path to SCM implementation
The concept of configuration is analogous to a bill of materials to assemble any product. Think of the product of an SCM as a system parts list.
Unlike hardware, software is not physical (tangible), is more complex, is easier to change, propagates change effects, and is data as well as logic.

SQA in Software Acquisition Life Cycle

1. Software Concept and Initiation Phase:
SQA should be involved in both writing and reviewing the Management Plan in order to assure that the processes, procedures, and standards identified in the plan areappropriate, clear, specific, and auditable. During thisphase, SQA also provides the QA section of the ManagementPlan.

2. Software Requirements Phase:
During the software requirements phase, SQA assures that software requirements are complete, testable, and properly expressed as functional, performance, and interface requirements.

3. Software Architectural (Preliminary) Design Phase:
SQA activities during the architectural (preliminary) design phase include:
Assuring adherence to approved design standards as designated in the Management Plan.
Assuring all software requirements are allocated to software components.
Assuring that a testing verification matrix exists and is kept up to date.
Assuring the Interface Control Documents are in agreement with the standard in form and content.
Reviewing PDR documentation and assuring that all action items are resolved.
Assuring the approved design is placed under configuration management.

4. Software Detailed Design Phase:
SQA activities during the detailed design phase include:
Assuring that approved design standards are followed.
Assuring that allocated modules are included in the detailed design.
Assuring that results of design inspections are included in the design.
Reviewing CDR documentation and assuring that all action items are resolved.

5. Software Implementation Phase:
SQA activities during the implementation phase include theaudit of:
Results of coding and design activities including the schedule contained in the Software Development Plan. Status of all deliverable items.
Configuration management activities and the software development library.
Nonconformance reporting and corrective action system.

6. Software Integration and Test Phase:
SQA activities during the integration and test phase include:
Assuring readiness for testing of all deliverable items.
Assuring that all tests are run according to test plans and procedures and that any nonconformances are reported and resolved.
Assuring that test reports are complete and correct.
Certifying that testing is complete and software and documentation are ready for delivery.
Participating in the Test Readiness Review and assuring all action items are completed.

7. Software Acceptance and Delivery Phase:
As a minimum, SQA activities during the software acceptance and delivery phase include assuring the performance of afinal configuration audit to demonstrate that alldeliverable items are ready for delivery.

8. Software Sustaining Engineering and Operations Phase:
During this phase, there will be mini-development cycles toenhance or correct the software.

During these development cycles, SQA conducts the appropriate phase-specific activities described above.

Formal Test Monitoring in SQA

SQA assures that formal software testing, such as acceptance testing, is done in accordance with plans and procedures.SQA reviews testing documentation for completeness and adherence to standards. The documentation review includes test plans, test specifications, test procedures, and test reports. SQA monitors testing and provides follow-up on nonconformances. By test monitoring, SQA assures software completeness and readiness for delivery.

The objectives of SQA in monitoring formal software testingare to assure that:
The test procedures are testing the software requirements in accordance with test plans.
The test procedures are verifiable.
The correct or "advertised" version of the software is being tested (by SQA monitoring of the CM activity).
The test procedures are followed.
Nonconformances occurring during testing (that is, any incident not expected in the test procedures) are noted and recorded.
Test reports are accurate and complete.
Regression testing is conducted to assure nonconformances have been corrected.
Resolution of all nonconformances takes place prior to delivery.
Software testing verifies that the software meets itsrequirements. T
he quality of testing is assured by verifying that project requirements are satisfied and that the testing process is in accordance with the test plans and procedures.

Verification and Validation Monitoring in SQA

SQA assures Verification and Validation (V&V) activities by monitoring technical reviews, inspections, and walkthroughs.
The SQA role in reviews, inspections, andwalkthroughs is to observe, participate as needed, andverify that they were properly conducted and documented.SQA also ensures that any actions required are assigned,documented, scheduled, and updated. Formal software reviews should be conducted at the end of each phase of the life cycle to identify problems and determine whether the interim product meets all applicable requirements.

Examples of formal reviews are thePreliminary Design Review (PDR), Critical Design Review(CDR), and Test Readiness Review (TRR). A review looks atthe overall picture of the product being developed to see if it satisfies its requirements. Reviews are part of the development process, designed to provide a ready/not-readydecision to begin the next phase. In formal reviews, actual work done is compared with established standards. SQA's main objective in reviews is to assure that the Managementand Development Plans have been followed, and that the product is ready to proceed with the next phase ofdevelopment. Although the decision to proceed is a management decision, SQA is responsible for advisingmanagement and participating in the decision. An inspection or walkthrough is a detailed examination of a product on a step-by-step or line-of-code by line-of-code basis to find errors. For inspections and walkthroughs, SQAassures, at a minimum, that the process is properlycompleted and that needed follow-up is done. The inspection process may be used to measure compliance to standards.

Configuration Management Monitoring in SQA

SQA assures that software Configuration Management (CM) activities are performed in accordance with the CM plans,standards, and procedures. SQA reviews the CM plans forcompliance with software CM policies and requirements andprovides follow-up for nonconformances. SQA audits the CMfunctions for adherence to standards and procedures andprepares reports of its findings. The CM activities monitored and audited by SQA includebaseline control, configuration identification,configuration control, configuration status accounting, andconfiguration authentication. SQA also monitors and auditsthe software library.
SQA assures that:
Baselines are established and consistently maintained for use in subsequent baseline development and control. Software configuration identification is consistent and accurate with respect to the numbering or naming of computer programs, software modules, software units, and associated software documents.
Configuration control is maintained such that the software configuration used in critical phases of testing, acceptance, and delivery is compatible with the associated documentation.
Configuration status accounting is performed accurately including the recording and reporting of data reflecting the software's configuration identification, proposed changes to the configuration identification, and the implementation status of approved changes.
Software configuration authentication is established by a series of configuration reviews and audits that exhibit the performance required by the software requirements specification and the configuration of the software is accurately reflected in the software design documents.
Software development libraries provide for proper handling of software code, documentation, media, and related data in their various forms and versions from the time of their initial approval or acceptance until they have been incorporated into the final media.
Approved changes to baselined software are made properly and consistently in all products, and no unauthorized changes are made.

Software Quality Assurance

A. Concepts and Definitions:
Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits.Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards.

B. Standards and Procedures:
Establishing standards and procedures for software development is critical, since these provide the frameworkfrom which the software evolves. Standards are the established criteria to which the software products are compared. Procedures are the established criteria to which the development and control processes are compared.Standards and procedures establish the prescribed methods for developing software; the SQA role is to ensure their existence and adequacy. Proper documentation of standards and procedures is necessary since the SQA activities of process monitoring, product evaluation, and auditing rely upon unequivocal definitions to measure project compliance.Types of standards include:


Documentation Standards specify form and content for planning, control, and product documentation and provide consistency throughout a project. The NASA Data Item Descriptions (DIDs) are documentation standards.

Design Standards specify the form and content of the design product. They provide rules and methods for translating the software requirements into the software design and for representing it in the design documentation.

Code Standards specify the language in which the code is to be written and define any restrictions on use of language features. They define legal language structures, style conventions, rules for data structures and interfaces, and internal code documentation.

Procedures are explicit steps to be followed in carrying outa process. All processes should have documented procedures.Examples of processes for which procedures are needed are configuration management, nonconformance reporting andcorrective action, testing, and formal inspections.If developed according to the NASA DID, the Management Plan describes the software development control processes, such as configuration management, for which there have to be procedures, and contains a list of the product standards.Standards are to be documented according to the Standards and Guidelines DID in the Product Specification. The planning activities required to assure that both products and processes comply with designated standards and procedures are described in the QA portion of the Management Plan.

C. Software Quality Assurance Activities:

Product evaluation and process monitoring are the SQA activities that assure the software development and control processes described in the project's Management Plan arecorrectly carried out and that the project's procedures andstandards are followed. Products are monitored for conformance to standards and processes are monitored for conformance to procedures. Audits are a key technique used to perform product evaluation and process monitoring.Review of the Management Plan should ensure that appropriate SQA approval points are built into these processes.
Product evaluation is an SQA activity that assures standards are being followed. Ideally, the first products monitored by SQA should be the project's standards and procedures. SQAassures that clear and achievable standards exist and then evaluates compliance of the software product to the established standards. Product evaluation assures that the software product reflects the requirements of the applicable standard(s) as identified in the Management Plan.
Process monitoring is an SQA activity that ensures that appropriate steps to carry out the process are being followed. SQA monitors processes by comparing the actual steps carried out with those in the documented procedures.The Assurance section of the Management Plan specifies the methods to be used by the SQA process monitoring activity.
A fundamental SQA technique is the audit, which looks at aprocess and/or a product in depth, comparing them to established procedures and standards. Audits are used to review management, technical, and assurance processes to provide an indication of the quality and status of the software product.
The purpose of an SQA audit is to assure that proper control procedures are being followed, that required documentation is maintained, and that the developer's status reports accurately reflect the status of the activity. The SQA product is an audit report to management consisting offindings and recommendations to bring the development into conformance with standards and/or procedures.

D. SQA Relationships to Other Assurance Activities : Some of the more important relationships of SQA to othermanagement and assurance activities are described below.

1. Configuration Management Monitoring

2. Verification and Validation Monitoring

3. Formal Test Monitoring

E. Software Quality Assurance: During the Software Acquisition Life Cycle In addition to the general activities described in subsections C and D, there are phase-specific SQA activities that should be conducted during the Software Acquisition Life Cycle. At the conclusion of each phase, SQA concurrence is a key element in the management decision to initiate the following life cycle phase. Suggested activities for each phase are described below.

1. Software Concept and Initiation Phase

2. Software Requirements Phase

3. Software Architectural (Preliminary) Design Phase

4. Software Detailed Design Phase

5. Software Implementation Phase

6. Software Integration and Test Phase

7. Software Acceptance and Delivery Phase

8. Software Sustaining Engineering and Operations Phase

F. Techniques and Tools: SQA should evaluate its needs for assurance tools versus those available off-the-shelf for applicability to the specific project, and must develop the others it requires.Useful tools might include audit and inspection check lists and automatic code standards analyzers.

Component Testing

What does it means when someone says component testing? The short answer is, it is anything you want it to be. It is the component testing perspective that is important and not the size of the pieces being tested. That perspective views the software being tested as intended for integration with other pieces rather than as a complete system in itself. This both helps to determine what features of the software are tested and how they are tested. One of the most intense arguments in testing object-oriented systems is whether detailed component testing is worth the effort. That leads to state an obvious axiom: Select a component for testing when the penalty for the component not working is greater than the effort required to test it.
It is the component testing perspective that is important and not the size of the pieces being tested. That perspective views the software being tested as intended for integration with other pieces rather than as a complete system in itself. This both helps to determine what features of the software are tested and how they are tested.

Which ones should we test?:
There are several situations in which the individual classes should be tested regardless of their size or complexity:
Reusable components - Components intended for reuse should be tested over a wider range of values than a component intended for a single focused use.
Domain components - Components that represent significant domain concepts should be tested both for correctness and for the faithfulness of the representation.
Commercial components - Components that will be sold as individual products should be tested not only as reusable components but also as potential sources of liability.

How thoroughly do we test?:
Before to answer the question of how thoroughly to test, the summary of some of what was presented in last months column[McGregor, 1997b] is added to the content. Risk analysis was applied to the task of identifying which parts of the system to test more intensely than the rest. An analysis was conducted on the requirements to determine potential business and technical risks for the development process. This analysis then mapped the risks identified at the requirements level onto individual use cases. Each use case was assigned a risk classification. All of the use cases within a category were tested to the same level of coverage. This same technique can be applied to the component level. That is, the risk classification of the use cases can be mapped onto the components. Thus not all components will be tested to the same coverage level just as not all use cases were tested to the same level.
I have already mentioned one criterion that could be used in a component-level risk analysis: whether the component is intended for reuse. The increased risk comes from the expectation that the component must respond correctly to a much wider ranger of inputs. Other criteria include the language features required for implementation of the component (using a relatively new feature such as exceptions in C++ is a higher risk), the complexity of the specification and the maturity of the development environment including the tools and the personnel.
The technique for identifying use cases that should be tested more thoroughly can be applied to the components that represent the concepts from the domain being manipulated in the use case. Once the use cases have been classified according to risk, the domain components referenced in each use case can be assigned the same risk classification as that of the use case. Of course it is seldom that simple. Since a domain object may participate in more than one use case, the risk categories for all of the use cases that reference that component must be combined to compute the risk value for the component.