Introduction to CVS | Know ABout CVS | Quick Start Guide


Introduction to CVS

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.
CVS is a production quality system in wide use around the world, including many free software projects.
While CVS stores individual file history in the same format as RCS, it offers the following significant advantages over RCS:

  • It can run scripts which you can supply to log CVS operations or enforce site-specific polices.
  • Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
  • In cases where several developers or teams want to each maintain their own version of the files, because of geography and/or policy, CVS’s vendor branches can import a version from another team (even if they don’t use CVS), and then CVS can merge the changes from the vendor branch with the latest files if that is what is desired.
  • Unreserved checkouts, allowing more than one developer to work on the same files at the same time.
  • CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
  • CVS servers run on most unix variants, and clients for Windows NT/95, OS/2 and VMS are also available. CVS will also operate in what is sometimes called server mode against local repositories on Windows 95/NT.
Tagged : / / / / / / / / / / / / /

CVS Best Practices – List of CVS Best Practices – CVS Tips


CVS Best Practices

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

Tagged : / / / / / / / / / / / / / /

What Is Software Configuration Management, its importance & how to implement it?


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.
This chapter will answer the following questions about software configuration management.

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, to name but a few issues to be discussed in this chapter.

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. This chapter will review SCM plan templates and provide you with a composite SCM plan template for use in any of your projects. We will cover the issues and basics for a sound software project CM system, 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


Tagged : / / / / / / / / / / / / / / / / / /

The Four Basic Requirements for SCM Process – SCM Guide


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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
Tagged : / / / / / / / / / / / / / / /

The symptoms of our software development malaise


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.

SCM Interacts 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.

Tagged : / / / / / / / / / / / / / / / /

What are the minimum features for SCM tools? – SCM Tools Essential Features


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.

Many configuration management tools in the market promise to fulfill more or less all of the requirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools to support software development and project management. 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. The following is an example of using that tool selection method for an SCM tool. This is simply an example, and it must be updated with individual key project success factors, tool requirements, and the tools available in the market based on the project’s schedule requirements.
A quick search of the market in SCM tools provided the list of potential candidates for the tool as shown in Table 31–1.

Table 31–1 SCM Tools

Name of Tool

Description and Company

Internet Address

AllChange 2000 SE


CCC/Harvest, CCC/Manager, CCC QuikTrak

Computer Associates (formerly Platinum)


Rational (formerly PureAtria)

CMVC, now VisualAge Team Connection

Configuration Management and Version Control, IBM



eChange Man


Enabler aqua



Computer Associates


Perforce Software


MERANT (formed by a combination of MicroFocus and Intersolv)

PVCS Dimensions

MERANT (formerly PCMS Dimensions from SQL Software)


Visible Software



Revision Control Engine (Visual RCE) DuraSoft GmbH


Lucent Technologies


Source Code Control System

Comes with most Unix distributions.


Software Configuration Library Manager, IBM


Source Code Manager, UniPress Software, Inc.



Source Integrity







McCabe and Associates


Soft Landing Systems

Visual Age TeamConnection


Visual Enabler

Soft Lab

Visual Source Safe

Microsoft Corp. (PC) / Metrowerks (Macintosh)

From the list, four were picked as possible commercial products that would meet the project’s requirements:

  • PCMS is an established product with strong all-round capability to manage the development of complex software projects over a wide range of platforms. Based on information in the public domain, PCMS has shown the greatest level of product development.
  • ClearCase is the dominant commercial SCM-tool in Unix development environments and is rapidly moving into NT client/server market development environments. It has achieved this principally by providing developers with transparent tools supporting their work environment and culture. The introduction of ClearTrack extends the all-around capability of the tool set by supporting the management and documentation of changes. After the recent liaison between Rational Software Corporation and Atria Software, Inc., an interesting merge of features between the object-oriented design tool Rational Rose and ClearCase may be expected.
  • Continuus/CM toolset is characterized by a strong embedded support for process, and its breadth of SCM coverage. The task-based process model is an intuitive approach to the management of change. Distributed development via direct links or over the Internet is simple to set up and operate. However, working across low-grade communication networks is difficult to set up and administer.
  • PVCS is the market-leading system for software configuration management by numbers sold. It is simple to use and has stood the test of time. Intersolv has gradually added functionality to Version Manager with associated products such as Tracker, Configuration Builder, and Gateway, and by integrating PVCS with many third-party tools.

Following an example from SEI, we formed a ranking system for comparing the tools. Table 31–2 shows the rating for the considered tools.
SEI Template for Ranking CM Plans.
Source: SEI, from Configuration Management Plans: The Beginning to your CM Solution.
The result of this first ranking allows one of the potential tools, PVCS, to be dropped. This would then leave three for the project manager and tool evaluation team to take a more in-depth look. Note that there has been no discussion of price at this time. Once the technical decision has been made, the cost decision should follow. Do not introduce price early in the evaluation. If there is discomfort with the technical capabilities and life cycle coverage of a tool, adding in a cost variable will only further confuse the decision. Many software project tools become less desirable after full life cycle cost is analyzed and estimated. Make the technical decision first.

Comparison of Four Commercial SCM Tools






Multiuser support





Intuitive GUI





Environment conformity










Flexibility in integrating other software development tools





Ease of setup





Modifiable models





Process management





Development phase support





Nondevelopment objects










These values are used to indicate ratings: 5 = Excellent; 4 = Good; 3 = Fair, 2 = Unsatisfactory; 1 = Unknown

As a final note on tools, working strictly in a Microsoft development environment with Microsoft tools working under Visual InterDev, Visual Source Safe (VSS) is included as an integral part of the tool suite. VSS is an adequate SCM tool for small commercial product development that is strictly targeted to Microsoft platforms. If you’re developing on Microsoft platforms and have delivery targets on Linux or Unix, investigate the use of WinCVS. WinCVS is a shareware package that is very capable in providing large-project, multiplatform SCM. It compares favorably with most and betters some commercial SCM tools.

Tagged : / / / / / / / / / / /

SCM Benefits the Organization in Four Major Ways – SCM Process Benefits


SCM benefits an organization in four areas: control, management, cost savings, and quality. 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.
SCM Benefits the Organization in Four Major Ways

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 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.

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.

Tagged : / / / / / / / / / / / / / / /

Potential SCM Problem Classes | SCM Potential considerations in an organization


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.
Potential SCM Problem Classes

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

A template that may be used in the creation of a software configuration management plan (SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues (organization, responsibility, etc.), SCM activities (configuration item identification, change control, status accounting, audit, and reviews), tools, techniques and methods, supplier control, and standards collection and retention.

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.


  1. Ability to see partitions
  2. Ability to see relationships
  3. Some technical ability
  4. System engineering orientation
  5. Programming


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


  1. Extreme attention to detail
  2. Ability to see congruence
  3. Ability to perceive what is missing
  4. Extensive experience with technical aspects of system engineering or software engineering

Status Accounting

  1. Ability to take notes and record data
  2. Ability to organize data
  3. Some technical familiarity
  4. System engineering orientation
  5. 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.

Tagged : / / / / / / / / / / / / / / / / / / /

What is Apache Ant? – Apache ant Overview


What is an apache ant?
Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make’s wrinkles.

Why another build tool when there is already make, gnumake, nmake, jam, and others?
Because all those tools have limitations that Ant’s original author couldn’t live with when developing software across multiple platforms.
Make-like tools are inherently shell-based — they evaluate a set of dependencies, and then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as UNIX, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. “Is my command not executing because I have a space in front of my tab!!!” said the original author of Ant way too many times.
Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform — to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on.

Tagged : / / / / / / / / / / / / / /