EETimes

Embedded Systems September 2000 Vol13_10

Issue link: http://dc.ee.ubm-us.com/i/71837

Contents of this Issue

Navigation

Page 177 of 229

Once the effort of using the SCM tool has been reigned in, it is time to take a careful look at the high-level concepts and how your organization is supporting them. The release notes do not contain any unique information; rathe r, they sum- marize in one convenient location everything that makes this release dif- ferent from the last one. Figure 1 shows a sample Release Note from a hypothetical proj ect. The first line identifies the label to which this note applies. Again , by using the label, all the components tha t make up thi s build can be retrieved with 100% confidence. It is not nece sary to keep track of th e relevant ve rsio n numbe r of every individual fil e. The next section lists all th e fil es that make this release dif- ferent from the previous one. Any modules that were added, removed, or changed are listed with: th e ver- sion number they had in th e previ- ous release, the version numbe r fo r th e current release, and a list of all branches from which the change were me rged (this proj ect uses the BDM). The third section is a high- level description of what was fi xed or othe rwise changed and why. Notice the Feature ID is an impleme ntatio n of th e Change Package concept. If some thing proves wrong with th e work done for th e Phone effort, it is possible to undo the change for each of the seven fil es tha t were affected by Phone. A new release would then be pe rformed to ensure a workin g mainline is always preserved. The last two lines identify a point of con- tact and a date of creati on. The point of contact is usually th e build boss. He is the one most in timately familiar with the release sin ce he is the one actually going through the process of building and releasing the software. The big picture This article has largely been about techniques for using your SCM tool efficiently and effectively. However, the tool itse lf is less than half tl1e whole configuration management pic- ture. Configurati on management encompasses th e following seven aspects: • Identification: ide ntifying the input componen ts • Control: the policy for allowing changes to the inpu t components • Status accounting: recording vital statistics (for example, change requests) about the product • Audit and review: verification of the product being derived from a known set of inputs • Manufacture/ build: the const.-uc- tion of product from its input com- ponents • Process management: ensuring the CM policy i being designed and followed • Team work: managing the interac- tions among multiple developers Once the effort of using the SCM tool has been reigned in, it is time to take a careful look at the high-level c6ncepts and how your organization is supporting them. Different SCM tools support different concepts at varying levels. For example, RCS is heavily centered on the identification and control aspects, but has minimal built- in audit and review capabili ties. Chances are, the concepts that tl1e tool you are using most strongly sup- ports are the ones your organization most strongly supports. However, effort should be made to supplement any configuration managemen t aspects not inherently pan of your tool's paradigm. The best place to tart the rest of your configura ti on management effort is the CM plan. The CM plan gathers in one location all the policy 176 SEPTEMBER 2000 Embedded Systems Programming decisions for implementing configura- tion management on your proj ect. Once the policy decisions have been made, a foundation exists to create the procedure which will be used over the course of the development effort. A full discussion of a CM Plan is out- side the scope of thi article. However, I suggest reading "Configuration Managemen t (CM) Plans: The Beginning to Your CM Solution" (by Nadine Bounds and Susan Dart) as an excelle nt place to start furthe r research. esp Allan Folz is a staff engineer at Logilws Inc. a software out-source and consulting company located in Indiana. He has devel- oped software for a variety of applications in the automotive industry in both product- intent and R&D settings. Allan received his BS in electrical engineering Jrorn Rose- Hulrnan Institute of Technology in Terre Haute, IN. He encourages correspondence and can be reached via e-rnail at afolz@logilws. com. References Bolinger, Don and Tan Bronson, "Applying RCS and SCCS," 1995. Available at www. orei lly. com I catalog! res/ no frames. him! Bounds, Nadine and Susan Dart, "Configuration Management (CM) Plans: The Beginning to Your CM Solution," 1993. Available at www. sei. emu. edullegacy /semi abstracts l abscm_plans.html. Dart, Susan. "Concepts in Configuration Management Systems." Available at www.sei.cmu.edullegacylscmlabstracts I abscm _concepts. htm I. Weber, Darcy Wiborg, "Change Sets Versus Change Packages: Comparing Implementations of Change-Based SCM," 1997. Available at www.continu- us. com! developers/ developersA C EG. html. Wingerd, Laura and Christoher Seiwald, "High-level Best Practices in Software Configuration Management," 1998. Available at www.perforce.com/ perforcel bestpradices.html.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10