Circular Logic. Robotic Tram Data Collection System Software Configuration Management Plan Version 2.3 4/8/ Circular Logic

Transcription

1 Circular Logic Robotic Tram Data Collection System Software Configuration Management Plan Version 2.3 4/8/ Circular Logic

2 Document Control Approval The Guidance Team and the customer will approve this document. Document Change Control Distribution List Initial Release: 1.0 Current Release: 2.3 Indicator of Last in Date of Last Review: 1/25/08 Date of Next Review: 1/25/08 Target Date for Next Update: 1/25/08 This following list of people shall receive a copy of this document every time a new version of this document becomes available: Guidance Team Members: Dr. Ann Gates Dr. Steve Roach Ernesto Medina Customer: Dr. Craig Tweedie Santonu Goswami Change Summary Software Team Members: Luis A. Garcia Erik Madrid Brandon Marin Javier Martinez Alfredo Saenz The following table details changes made between versions of this document Version Date Modifier Description 1.0 1/15/08 Erik Madrid Initial setup created distribution list, document change control, added the title, rough draft of introduction, referenced work 1.1 1/17/08 Erik Madrid Creation of sections 2.1 and 2.2 Brandon Marin 1.2 1/23/08 Javier Martinez Creation of section /23/08 Brandon Marin Creation of section 3.2 & Change Request form 1.4 1/23/08 Luis A. Garcia Modification of section 2.2 revised labeling similarly to MSDN standards 1.5 1/23/08 Erik Madrid Creation of section 3.3 Creation of Tortoise SVN tutorial Modification of section 3.1 to comply with content from template Modification of section 2.2 created backup plan 1

3 Modification of 2.1 to comply with template content 1.6 1/24/08 Alfredo Saenz Creation of section /24/08 Javier Martinez Alfredo Saenz Modification of section 4 according to guidelines given during the meeting 1.7 1/24/08 Luis A. Garcia Modification of section 4 to comply with content from template Editing of sections 2.1, 3.1, 3.2, /24/08 Brandon Marin Modification of section 1 to include purpose and intended audience Modification of section 3.2 to changed discussed in meeting Editing of sections 2.1, 2.2, /24/08 Erik Madrid Initial formatting verified document complies with APA standards 2.0 1/24/08 Brandon Modification of formatting to include appendices and images Modification to all sections wrote introductions to all sections 2.1 1/25/08 Erik Madrid Completion of 1 st draft 2.2 1/25/08 Luis A. Garcia Reviewed version 2.1 for spelling grammar and content 2.3 1/25/08 Erik Madrid Brandon Marin Luis A. Garcia Javier Martinez Modification to flow chart to include changes Final walkthrough edited document for grammar, spelling, and content. 2

4 TABLE OF CONTENTS DOCUMENT CONTROL... 1 APPROVAL... 1 DOCUMENT CHANGE CONTROL... 1 DISTRIBUTION LIST... 1 CHANGE SUMMARY INTRODUCTION PURPOSE AND INTENDED AUDIENCE OVERVIEW REFERENCES SOFTWARE CONFIGURATION IDENTIFICATION SOFTWARE CONFIGURATION ITEM IDENTIFICATION SOFTWARE CONFIGURATION ITEM ORGANIZATION SOFTWARE CONFIGURATION CONTROL DOCUMENTATION CONFIGURATION CONTROL BOARD PROCEDURES SOFTWARE CONFIGURATION AUDITING APPENDIX CHANGE REQUEST FORM TORTOISE SVN TUTORIAL Checking Out a Repository Locking a Directory or Document in the Repository Updating the Repository Committing Changes to the Repository Adding a File or Directory to the Repository Removing a File or Directory from the Repository CHANGE REQUEST FLOW CHART

5 FIGURES Figure 1 SVN Checkout Option Figure 2 Checkout Dialog Figure 3 Server Certificate Prompt Figure 4 Password Prompt Figure 5 Checkout Status and Confirmation Dialog Figure 6 Get Lock Option Figure 7 Lock Files Message Dialog Figure 8 Lock Finished Dialog Figure 9 SVN Update Option Figure 10 Update Summary Dialog Figure 11 Commit Option Figure 12 Enter Log Message Dialog Figure 13 Add Option Figure 14 Add Confirmation Dialog Figure 15 Add Information Dialog Figure 16 Delete Option Figure 17 Change Request Form Evaluation

6 1. Introduction Robotic Tram Data Collection System (RTDCS) is a project aimed at collecting, storing, displaying, and analyzing data measured in the Barrow Environmental Observatory.[1] The configuration management plan (CMP) establishes a configuration management (CM) approach that maintains the integrity of the RTDCS project and provides traceability for changes incorporated into the project. The CM process defines the technical and administrative actions for identifying the functional, performance, and physical characteristics of configuration items and controls the changes to those characteristics Purpose and Intended Audience The purpose of a software CMP is to control the system differences and changes in the development process to minimize risk and error.[2] CMP is essential for a project in which many users contribute to its life cycle. It minimizes complexity by enabling the controlled management of configuration items as they evolve in all stages of development and maintenance. CM implements a process in which the development team identifies, communicates, implements, documents, and manages changes in the project. The CMP helps to maintain the integrity of the items that have been placed under its control. This will assure developers that they will be involved in the change process. CM will facilitate and ensure that appropriate communications occur among all developers. This guarantees that each developer has input on the overall scope of the project. This document is intended for persons involved in the development of this project Overview The CMP contains three core sections: Software Configuration Identification, Software Configuration Control, and Software Configuration Auditing. The software configuration identification section identifies all entities that will change throughout the life of the project. This section also defines a naming convention paradigm for version control and describes the directory structure of the database. The software configuration control section defines rules and procedures for preparing, evaluating, and approving or disapproving all changes to the configuration items throughout the life cycle.[3] This section includes procedures on documenting, evaluating, and managing changes to the system configuration. The software configuration auditing section defines a mechanism for maintaining consistency and history of versions and variants.[3] This section outlines the procedures for examining the correctness and accuracy of the system configuration References [1] Logic, Circular. Feasibility Report. El Paso : UTEP SE, [2] Pfleeger, S. & Atlee, J.M. Software Engineering Theory and Practice. s.l. : Prentice Hall, [3] Gates, Ann & Roach, S. Software Configuration Management Plan. [Microsoft Power Point] EL Paso : s.n., [4] MSDN..NET Framework Developer Center. [Online] Microsoft Software Configuration Identification 2.1. Software Configuration Item Identification To ensure that guidelines of configuration management are adhered to, the system configuration will be comprised of the following components: 5

7 Source code Test Suites Graphical User Interface Configuration Management Document (CFG) Software Code Inspection Document Software Design Document (SDD) Meeting Records* System Requirements Specification Document (SRS)* Any modifications to these documents will employ the mechanisms described in section 3 of this document. *Document will be located in the repository for reference only 2.2. Software Configuration Item Organization Baselines and updates to baselines for the various items that are managed, in particular code, will adhere to the following versioning convention which is a slight modification on the system used by the Version class found in the.net platform: major.minor[.build]. [4] Major Items with the same name but a different major version are not interchangeable. This would be appropriate where backwards compatibility is not assumed. For example, versions 1.1 and 2.0 of component A would not be interchangeable. The major number would increment, for example, when a component s API changes. Minor When the major number and name are the same for a particular item and the minor is different, this indicates significant enhancement with backwards compatibility intended.. For example, versions 1.1 and 1.4 of component A would be interchangeable. This increment would be suitable for when the API of a component remains the same and only the internal implementation of a method changes. Build This is an optional number that represents a recompilation of the same source code. For example, if a different version of a tool was used to compile the code the build number would be appended to the version number. Configuration management will transpire through a Subversion (SVN) control repository that will reside on the software engineering class server located at SVN serves as a repository management tool that is compatible with both Microsoft Windows and Posix based operating systems. In order to use SVN and contribute to a repository, the developers must download an SVN client. Tortoise SVN is an SVN client shell extension for Microsoft Windows, which is available at The developers will use version of Tortoise SVN, which is the most current version available. Tigris maintains a SVN client that is applicable on most Posix based operating systems (e.g. Linux and Unix). The developers will use version of Tigris Linux Subversion client. If Tigris releases a new version of either Tortoise SVN or the Subversion client for Linux, the configuration control board (CCB) will decide whether the developers will adopt the new release. Appendix 5.2 contains a general tutorial on how to use Tortoise SVN. The root directory will contain three child directories: Archive, Project, and Documents. The Archive directory will contain a Document Archive directory and a Project Archive directory. After each new baseline, any previously related item will be copied and placed into the respected archive directory with the appropriate label. The Documents directory will contain the documents listed in section 2.1. Each document will reside in a directory with that Document s title. For example, the SRS will reside in /Documents/SRS/. A backup scheme will protect all files in the system configuration from loss or potential data corruption. A backup can consist of the one of the following: full or incremental. A full backup will back up all files in the repository. A full backup will be performed automatically every week on Sunday at midnight Mountain Standard Time (MST). An incremental backup is a type of backup that only backs up files that have changed since any incremental or full backup. A daily incremental backup will be performed automatically at midnight MST. The person designated as the lead of a deliverable will be responsible for ensuring that the backup plan is operating normally. In the event that the repository needs recovering, Erik Madrid will be in 6

8 charge of restoring any file that is lost or corrupted. Microsoft Window s backup application will perform the scheduled backups. It will compress the backup file, which will reside on the sefall2 computer in the SE lab. SVN will allow multiple developers the ability to work in parallel on the system at any given point in time (see section 3.3 for specific access and modification protocols). SVN allows users to check-out the most recent version of a system configuration. The developers can then work on the system without affecting the work of other s. When the developer has finished making changes to the system, he/she can commit his/her changes. When changes are committed, SVN alerts the user if he/she has a configuration that is inconsistent with the most recent version in the repository. The user can then decide if he/she wants to either merge the changes or perform a comparison against the version on the repository. Once the user commits the changes, SVN updates the release number of all files with a new release number. 3. Software Configuration Control 3.1. Documentation All changes to items that will be inherent in the repository will be documented in the form of a Change Request form. This form will act as a record containing the information that defines a proposed change to a software system. This documentation will make the tracking of manipulated changes more coherent to the CCB and will allow for more control to the changes made to the software system. A change to the system configuration is defined as any modification to any item that changes the state of the system configuration. In particular, a change to the source code is defined to be any change that affects the performance or functionality of the software system. A change request can be initiated by a developer or the CCB. The Change Request form will contain the following fields to be filled out by the developers: Request Number, Request Date, Request Title, Originator s Name, Originator s Phone/ , Priority, Assigned To, Start Date, Delivery Date, Request Description, Justification, Alternative Solutions, Impact Assessment, Recommendation, Authorization. The Request Number field will contain a numerical value related to the occurrence of the incident. The Request Date field will contain the date the developer or the configuration management board initiated the request. The Request Title field will contain a descriptive title for the change request. The Originator s Name field will contain the name of the developer or party that initiated the request. The Originator s Phone/ will contain the developer s respective contact information. The Priority field will contain a designation of either Routine or Urgent. The Assigned To field will contain the name of the developer responsible for executing the change. The Start Date field will contain the date the developer is to commence the change. The Delivery Date field will contain the date the developer is expected to complete the change. The Request Description field will contain a detailed description of the request change. The Justification field will contain a reason as to why the originator requested the change. The Alternative Solutions field will contain options to the proposed change. The Impact Assessment field will outline all components in the system configuration that the 7

9 change will affect. The Recommendation field will contain the CCB s final decision on the proposed change. The Authorization field will contain the signatures of all members present in the recommendation. Appendix 5.1 contains the CR template Configuration Control Board Configuration control is the process for tracking and managing system and subsystem changes. To ensure the integrity of the configuration control process, Circular Logic will establish the aforementioned CCB to evaluate and authorize the changes to the system configuration. The board s primary roles are to: assess the impact and desirability of proposed changes, authorize the establishment of project baselines and identification of configuration items, review and authorize changes to project baselines, monitor changes and updates to project requirements as part of CM and approve the creation of deliverables into the project s baseline directory. The body of the board will consist of the entire development team. Two distinct tiers will make up the CCB. The first tier holds the position of CCB manager. The project leader of the current task holds this position. The manager has the approval power of the board s responsibilities. The second tier holds the remaining members of the development team. The members of this tier may vote to override the CCB manager s decision. A majority vote is required to override the CCB manager. If a split decision occurs, between the second tier and the first tier, the guidance team will decide the approval. The CCB reviews and determines the disposition of all requests to change the items that are under its control (code, documentation, and data). A change request is the only mechanism for initiating changes to the system configuration. The change process starts by the submission of a change request to the CCB manager. After the manager reviews and logs the change, the manager distributes copies of the document to remaining members of the CCB prior to the next meeting. The exception to the above statement is that the change request originator has marked the change request as URGENT. The manager will take into consideration its immediate operational impact and will either approve or reduce its priority to ROUTINE. If the priority is reduced, the CCB will review the document during their next meeting. At a CCB meeting, the CCB evaluates the request and determines the approval of the change request. The CCB determines approval by the following factors: the functional aspect of the change (i.e., the consequences of not implementing the change and the complexity of the change), current phase of the project, possible alternatives to the proposed change, resources required to implement the change, documentation requirements, integration and testing requirements and the effects on other processing and interface of other agencies. Once the decision of the CCB is made, the appropriate actions are taken to facilitate the change. The details of these actions are defined in section Procedures Subversion will control all the configuration items in the repository outlined in section 2.1. At the beginning of the development phase, each developer will checkout the baseline repository. When the CCB decides a developer is to change a component of the system configuration, that developer will have exclusive access to that component and any dependent of that component. First, the developer will update the repository (to ensure that he/she has the current version) and lock that component. Locking a component ensures that other developers cannot interfere with the change. The developer will then describe the reason for placing a lock on the component by entering a message in the message dialog provided by the Subversion client. The conditions for releasing the lock on the section are the following: 8

10 If the configuration item is a configuration document, a technical review has been made and the CCB has approved the document as a final version; If the configuration item is source code: o the source code will compile without error, o the developer will have written test cases for all modified portions of the source code, o the source code will have passed all unit or regression testing and o any appropriate documentation changes have been made. Only after the change meets these requirements and the CCB has approved the results of the change will the developer release the lock on the component. Upon release, the developer will commit his/her changes by performing an SVN commit. The developer will log changes by entering a message in the message dialog provided by the Subversion client. If, for any reason, a member of the team feels that a document should be reverted to a previous version, the CCB will consider the request and decide whether the reversion is necessary. This will be done by performing a revert action provided by the Subversion client. The developer reverting the document(s) will log the reason for reverting by entering a message in the message dialog provided by the Subversion client. The person responsible for enforcing these guidelines will be the person designated as the lead on the project task. This person will be responsible for ensuring: each assigned component is locked, the developers meet the guidelines of releasing a lock on a component and the developers correctly log changes in the SVN client. This person will also be responsible for bringing any discrepancies to the attention of the CCB. The process for instantiating a new version will adhere to the following: the CCB has approved the change, the developer will create the needed directories and/or files, the developer will lock the newly instantiated component, upon completion, the developer will unlock the component, the developer will commit the change and the developer will document the additions in the appropriate SVN log. 4. Software Configuration Auditing This document has described the software configuration plan that will be employed throughout development of the software. This section describes the auditing process that will be followed to ensure that the standards described in the rest of this document are followed and that a consistency is maintained during development. The configuration auditing board (CAB) will consist of two members assigned by the CCB manager. These members have the responsibility of reviewing the CCB change request decisions and the appropriate documentation of those decisions. Once the CCB has reached a decision regarding a change request form, the CAB will perform an audit. An audit consists of: ensuring the necessary documentation has been made and filed, determine if the decision of the board is correct from the documentation on file and create an audit report. The audit report will address the following questions: did the CCB follow the guidelines set by the CMP 9

11 have the CCB recorded the necessary documents for accepting or rejecting a change report has all the configuration item been properly integrated into the project Through these audit reports, the development team can be assured that development policies are adhered to and that the process of making changes and reviewing these changes is a formal one. 10

12 5. Appendix 5.1. Change Request Form 11

13 12

14 5.2. Tortoise SVN Tutorial Checking Out a Repository In a newly created directory (e.g., folder ), right-click inside the folder. A menu will emerge. Click on the SVN Checkout option (see Fig.1) Figure 1 SVN Checkout Option 13

15 A Checkout dialog will emerge. Enter the path of the repository into the URL of repository: text field in the Checkout dialog (see Fig. 2) and click on Ok. Figure 2 Checkout Dialog 14

16 Tortoise SVN will prompt you to accept a server certificate (see Fig. 3) because this is the first time you checkout this repository. It is recommended that you accept this certificate permanently. Figure 3 Server Certificate Prompt (Courtesy of 15

17 Next, Tortoise SVN will prompt you to enter the repository password (see Fig. 4). Enter the username and password and click on Ok. Be sure to check the save permanently option or Tortoise SVN will prompt you to enter a username and password each time you perform a Subversion task Figure 4 Password Prompt (Courtesy of 16

18 If you did everything correctly, Tortoise SVN will display a dialog indicating which files it is copying to your local computer. Click on Ok to close the dialog. (see Fig. 5). Figure 5 Checkout Status and Confirmation Dialog Congratulations! Now you have successfully checked out the repository. You can now begin to modify any document that is not locked or does not have elevated privileges. 17

19 Locking a Directory or Document in the Repository Locking a file or directory in your repository can be a useful tool when you want to ensure that no one interferes with what you are working on. First, right click on the file or directory that you wish to lock. A menu will emerge. Select the Tortoise SVN sub-menu. Now, select the Get Lock option (see Fig. 6). Figure 6 Get Lock Option 18

20 Next, a Lock Files dialog will appear (see Fig.7). Enter a message as to why you are locking the files and click on Ok. Figure 7 Lock Files Message Dialog 19

21 A Lock Finished! dialog will appear illustrating a summary of the locked files (see Fig. 8). To close the dialog, click on Ok. Figure 8 Lock Finished Dialog 20

22 Updating the Repository Before you work on a repository, it is a good idea to update it to ensure that you have the latest revision of all the files stored on SVN server. To update the repository, go to the directory that you wish to update and right click in the folder. A menu will emerge (see Fig. 9). Click on SVN Update. Figure 9 SVN Update Option 21

23 A dialog will emerge illustrating a summary of the updated documents(see Fig. 10). If the files you contain are up-to-date, the summary will not contain any files. Click on Ok to close the dialog Figure 10 Update Summary Dialog 22

24 Committing Changes to the Repository Performing a commit will merge your changes to the repository. To commit your changes, right-click on the folder or a file that you wish to commit and a menu will emerge (see Fig. 11). Select the SVN Commit option. Figure 11 Commit Option 23

25 An Enter Log Message dialog will emerge (see Fig. 12). Enter a detailed message as to why you are committing your changes. Figure 12 Enter Log Message Dialog 24

26 Adding a File or Directory to the Repository To add a file or directory to the repository, right-click on the file or directory. A menu will emerge (see Fig. 13). Select the Tortoise SVN submenu. Now, select the Add option. Figure 13 Add Option 25

27 An Add confirmation dialog will emerge that illustrates the file(s) and/or directories that Tortoise SVN should add (see Fig.14). Verify you have selected the proper files. To apply the changes, click on Ok. Figure 14 Add Confirmation Dialog 26

28 Finally, an information dialog will emerge indicating which items(s) was/were added (see Fig. 15). To close this dialog, click on the Ok button. Now the file is in the repository for other developers to view and modify. Remember that all other developers must perform an Update in order to receive the item(s). Figure 15 Add Information Dialog 27

29 Removing a File or Directory from the Repository To remove a file or directory from the repository, right-click on the file or directory. A menu will emerge (see Fig. 16). Select the Tortoise SVN submenu. Now, select the Delete option. Figure 16 Delete Option 28

30 Next, Tortoise SVN will delete the item(s) from your directory. Finally, perform a SVN commit in order for your changes to take effect. Remember that other developers will have to update their working copies of the repository for your changes to be seen on their copies of the repository. 29

31 5.3. Change Request Flow Chart Figure 17 Change Request Form 30