Appendix A. Configuration Management Process Model: A Software Code Example
| In this example, an object's unique identification is indicated by <CI name > . ( "CI" stands for "configuration item.") The name alone is depicted as <Module> . The example includes only a few procedure descriptions and templates referenced in the flow diagrams.
Written by: NN Date: 8-31-2001 Change History This is the first accepted version. Purpose Ensure that configuration management is performed in a structured way. Scope This process area description is valid for source code and related items developed in the Software Development and Test Department. Responsibility Ms. Anni Capella holds the overall responsibility for configuration management. Input Source code files and related files. Procedure This process area is divided into four main processes:
Each process is shown with its activities below.
Output Source code files and corresponding files in controlled storage, associated metadata, and report facilities. References SDT- CM -P01 Unique Identification SDT- CM -P02 Placement in Storage SDT- CM -P03 Release for Usage SDT- CM -P04 Release for Production SDT- CM -P05 Event Registration SDT- CM -P06 Event and Change Request Life Cycles SDT- CM -P07 Extraction of Predefined Report SDT- CM -P08 Extraction of Ad Hoc Report SDT- CM -T01 Source Code Header SDT- CM -T02 Source Code Approval Form SDT- CM -T03 Source Code Release Request SDT- CM -T04 Event Registration SDT- CM -T05 Change Request SDT- CM -T06 Predefined Status Reports Reference to other process area: SDT-CP-A01 Code Production
Written by: NN Date: 9-05 - 2001 Change History Correction of scope since the version dated 8-31-2001. Purpose Ensure that all source code files and related items are stored in the controlled library when they are supposed to be under configuration management. Scope This procedure is used when source code files and related files are approved according to ATP-QA-P03 and therefore to be placed under configuration management. This means that the source module is in a state where it can compile and at least one operation is working such that modules using it may benefit from the implemented functionality. Responsibility The developer of the file to be placed in storage is responsible for this being done correctly. Input A source code module and related file(s) (objects) to become configuration items. An approval form, SDT- CM -T02 , correctly filled in for the module. Procedure The command to use to place an object in storage is Format: propose [-h -u -b] <CI name> This command saves the configuration item with status "proposed" and copies and creates derived files according to the type of configuration item ( -h for header file; -u for unit, -b for build). After successful storage, the approval form, SDT- CM -T02 , must be handed to the project manager. Explanation: First of all, .hxx and .h files are to be shared. This is made possible by issuing the command propose h <Module>.hxx . This command will prompt for a comment and save the new version of <Module>.hxx in the controlled area, where it receives the status "proposed." It will then retrieve the <Module>.hxx in a read-only version into the appropriate subdirectory in the development area and recompile whatever needs to be recompiled in this area as a consequence of the new .hxx file. This must be done before the <Module>.cxx may be proposed, which is done by issuing the command propose <Module>.cxx . This command will check that the <Module>.o file was actually created with the latest available .h and .hxx files. If not, the proposal is rejected and the developer must ensure that the module is still in a "useful" state. If everything is OK, the command will prompt for a comment and
This is illustrated below, where <Module> = U1 . Output A configuration item in controlled storage with the status "proposed." References SDT- CM -T02 Source Code Approval Form Reference to other process area: ATP-QA-P03 Approval of Source Code
Written by: NN Date: 8-31-2001 Change History This is the first accepted version. Purpose Ensure that a source code file and related items are extracted correctly when they are going to be used as the basis for production of a new version of the same file family. Scope This procedure is used when source code files or related files are the basis. Responsibility The developer of the file is responsible for the release of a file as a basis for production. Input A change request for the module, stating what needs to be changed Procedure The commands to use to extract objects from storage as basis for production are Format: user -update This command copies all files from the central marfdev area to the developer's area. This is done to get the production started. Format: make -f Makefile.<CI name> depend This command creates the <CI name>_dep.txt file, containing the names of all files on which <CI name> depends directly for compilation. This file must be available during development and test, as all other commands may use the information in it. Format: retrv -lock <CI name> This command retrieves a writable version of <CI name> from the marfdev area to the developer's area and locks the configuration item for other developers. Format: get-deps [-u -b] [-nocheck] <CI name> This command copies files on which the CI depends from the marfdev area to the developer's area, for either a unit CI ( -u ) or a build CI ( -b ). If the -nocheck option is not given, all dependent configuration items will be checked for proper status. Explanation: When the developer starts work on <Module> , he/she must retrieve a working copy of <Module>.cxx from the AtFS repository to his/her own area. This is done by issuing the command retrv -lock <Module>.cxx to place a writable copy of the <Module>.cxx in the user's area, where it has the status "busy." This is illustrated below, where <Module> = U1 . The same may be done for <Module>.hxx if the developer needs to work on that file as well. The developer then needs to get all the files necessary for compilation and linking of <Module> . This is done by issuing the command get-deps -nocheck <Module>.cxx to copy the newest version of all .h and .hxx files on which <Module>.cxx directly depends to the developer's area (using the -dep.txt file) and to copy all object libraries to the users' area. This command may be used anytime during development to ensure that work is done with the newest available version of the dependency files. Note that files retrieved by get-deps may not be changed by the developera changed version cannot be stored. This is illustrated below. Output A set of files to be used as the basis for development of the new version of <Module>.cxx References None.
Written by: NN Date: 8-31-2001 Change History This is the first accepted version. Purpose Ensure that events are registered correctly. Scope This procedure is used when an event is identified for a source code file or a related file. Responsibility Everybody who identifies an event in a source code file or a related file is responsible for correctly registering the event. Input An identified event and all possible documentation to support the description of the event Procedure In Word, create a new file, based on the event registration template SDT- CM -T04 . Fill in the event registration. Mail the event registration and any supporting documentation to CCB@marfdev.com. Output An event registration. A receipt will be mailed. References SDT- CM -T04 Event Registration
Written by: NN Date: 8-31-2001 Change History This is the first accepted version. Content #ifndef FILENAME_H /**************************************************************** file: $Source$ $Revision$ Responsible $Author$ checked in at $Date$ Log: $Log$ ******************************************************************/ #endif Example 1: Before first placement in storage #ifndef MOTOR_H /**************************************************************** file: $Source$ $Revision$ Responsible $Author$ checked in at $Date$ Log: $Log$ ******************************************************************/ typedef double speed; typedef double position; typedef double time; speed ac(time t); position where(speed s, position p, time t); #endif Example 2: After a change request #ifndef MOTOR_H /**************************************************************** file: $Source: /home/cj/amj/motor.h,v $ $Revision: 1.2 $ Responsible $Author: cj $ checked in at $Date: 2002/02/06 22:54:39 $ Log: $Log: motor.h,v $ Revision 1.2 2002/02/06 22:54:39 cj add dif function(request 33) Revision 1.1 2002/02/06 22:52:02 cj Initial revision ******************************************************************/ typedef double speed; typedef double position; typedef double time; speed ac(time t); position where(speed s, position p, time t); time dif(position p1, position p2, speed s); #  |
EAN: 2147483647
Pages: 181