CENG492 SENIOR DESIGN PROJECT AND SEMINAR II SOFTWARE CONFIGURATION MANAGEMENT PLAN

Transcription

1 CENG492 SENIOR DESIGN PROJECT AND SEMINAR II SOFTWARE CONFIGURATION MANAGEMENT PLAN by Group LaPaix Subject on COMPUTERIZED READING SYSTEM FOR BLINDS DEPARTMENT OF COMPUTER ENGINEERING METU ANKARA

2 TABLE OF CONTENTS 1. INTRODUCTION PURPOSE OF CONFIGURATION MANAGEMENT PLAN SCOPE OF DOCUMENT ACRONYMS AND ABBREVIATIONS DOCUMENT REFERENCES THE ORGANIZATION CM FRAMEWORK ORGANIZATION AND RESPONBILITIES TOOLS AND INFRASTRUCTURE THE CM PROCESS IDENTIFICATION MANAGEMENT AND CONTROL CONFIGURATION STATUS ACCOUNTING AUDITING PROJECT SCHEDULES AND CM MILESTONES PROJECT RESOURCES PLAN OPTIMIZATION... 9 APPENDIX

3 1. INTRODUCTION 1.1 PURPOSE OF CONFIGURATION MANAGEMENT PLAN Configuration Management is required in order to identify the best configuration, to control changes and to keep track of change implementations. Throughout this paper, you can find our Configuration Management Plan, and how we are going to achieve version control, change control, and auditing of the changes within the project team. This paper is mainly about the formalization of the process of making changes to our - under development- project so that each team member will be aware of which version contains what properties. To preserve consistency and prevent any conflicts between the group members we are going to set up a formal configuration management plan. Configuration Management Plan is essential for three main reasons. First of all, configuration management activities will be planned. Next, our work products will be defined and controlled. Finally, affected team members will always be informed about the requirements of the change, status of each version of the project. 1.2 SCOPE OF DOCUMENT This document describes the Configuration Management issues and actions for project development of group LaPaix. It explains how the Software Configuration Management tasks like configuration management identification, management, change control, status accounting, and audits will be performed. 1.3 ACRONYMS AND ABBREVIATIONS CM : Configuration Management CMP: Configuration Management Plan SCM: Software Configuration Management Plan CI: Configuration Item CSA: Configuration Status Accounting SCA : Software Configuration Audit PCA : Physical Configuration Audit FTR : Formal Technical Reviews CVS : Concurrent Versions System OCR : Optical Character Recognition TTS : Text to Speech Synthesis 3

4 1.4 DOCUMENT REFERENCES 1.IEEE Guide to Software Configuration Management (Std ) 2. Concurrent Version System Information, 2. THE ORGANIZATION CM FRAMEWORK 2.1 ORGANIZATION AND RESPONBILITIES We are a small project group of four members. Therefore, the organizational structure for CM is much simpler than real-life software project teams. We have decided on the following organizational chart for configuration management. Configuration Manager Configuration Evaluation Subteam Configuration Review Subteam Configuration manager is at the top of our mini-organization. Nur Koç is the configuration management leader. She will be responsible for planning the configuration management activities such as coordination of sub-teams for auditing, change request meetings, continuous change control reports. We have divided the main configuration management issues into two different sub parts. Configuration Evaluation subteam - Asiye Aydın and Nur Koç - is responsible for evaluating change request of one of the group members. After this pre-evaluation, that team will hold a meeting and perform brainstorming for the new part. This sub team will evaluate the time required to implement the change, and the member(s) who will be implementing the part and which members will be affected by the change. Therefore, schedule update is responsibility of this sub team. Configuration Review subteam - Seçil Arslan and Öznur Kırmemiş - will be responsible for testing and one of the group members, implements proper integration of the change after the required change. Therefore, this team will also provide auditing of changes and new versions by updating the announcement part of the website and getting contact with other members via to ensure that every member is informed about the status of the project. 4

5 2.2 TOOLS AND INFRASTRUCTURE In our project, the main configuration management tool will be the version control system. The system is CVS, which is provided by the department (Department of Computer Engineering, METU). CVS is installed in department machines, and since we develop our project in Visual Studio.NET environment, every member will first transfer her own source code via ftp to her directory in the department account. Our project is composed of four main components, the developments of which are distributed two by two to sub teams. The modules are independent of each other, they only interact via signals or interconnection signals and for each module exactly two people will be aware of what is being done. Therefore, we are somehow lucky in change control issues and we do not think to use a change control tool. In addition, this structure makes the intercommunication among members and approval of changes in the modules trouble-free. However, we will perform all the SCM tasks appropriately although we are a small sized and easy to manage project team. Other than the project infrastructure described above, software libraries will be built and used as tools in status accounting phases, and documentation. These libraries will be: 1) Development libraries (dynamic) : They store configuration items that are being written or unit tested. 2) Master libraries (controlled): They store current baseline configuration items. 3) Archive libraries (static) : They store release configuration items. Configuration items in archives cannot be changed. All configuration items will be stored on controlled media (each member's hard disk and CDs), procedures for backup of development libraries will be established, and copies of master and archive libraries will be available. 3. THE CM PROCESS 3.1 IDENTIFICATION In this part, we will identify and describe the characteristics of the code, specification, design, and data elements of the project, which need control during project lifecycle. These are called configuration items that include software, hardware, communications, and documentation and all affected changes to these items. Firstly, we have to identify the items, which will be obtained in CM control. Documents include all necessary information to provide a full technical description of the characteristics of the configuration items that require control. Configuration identification shall be applied to all developed systems including code, hardware, environment, and related documentation. From now on, we have defined the baselines. Baselines are composed of all configuration items describing to a system at a point in time. We use the baselines to maintain traceability of the changes in the configuration items during the project life cycle. Our project baselines are: 5

6 Software Requirements Specification System/ Subsystem Design Description Software Configuration Management Plan System Test Plan Unit Test Executables User Manual (both technical and non-technical) Installation Plan The items integrated in system baselines are stored in an electronic media format once changes are made. We will check out configuration items for modification using CVS checkout procedure. When somebody finishes working on the configuration item, changes will be committed with CVS commit procedure. For the naming convention of the CVS, every Configuration Item (CI) will receive a new version number when there has been a change to its established baseline. Each previous version will be stored in a corresponding CI directory under version_n (0<n ). We will name each CI in Version X.Y.Z format. In which X represent the CI name, Y represent the component of CI and Z represent section of the component if CI can be broken into individual parts(see Appendix). 3.2 MANAGEMENT AND CONTROL Managing configuration is an important aspect that includes many practices like change control as well as tools that will be used for configuration management practices. These tasks make it easier to control the progressing of the project, and improve communication among project team members and minimize problems when integrating each member's work Change Control Configuration change control is the most important aspect of the CMP. It combines the procedures defined in this plan and some automated tools (CVS) to provide a mechanism for controlling change. It consists of a systematic evaluation/review, coordination, prioritization, approval/disapproval, and implementation of all change requests made during the lifetime of our project. As known our team consists of four members, so in comparison to bigger project teams and their works, change control is an easier task for us. However, it is vital to define a procedure. All of the change requests for any software configuration item will be handled according to the procedure described below: 6

7 Any team member may recognize a need for change at any time during the lifetime of the project. Every team member must document her change request. This document should include reason for change, list of all affected configuration items, and description of the change and priority of the change (i.e., urgent, necessary etc.). All change requests and results will be documented and saved appropriately. All team members will review the request and reach a consensus as to the course of action that needs to be taken. If the change request is approved, then responsible team members will implement the change. The team will review the implemented change to verify its correctness and then test it System Building System building includes tasks related to development, engineering, and building. It includes combining source components of a system into components that execute on a predetermined configuration. One of the most important aspects of system building process is that, the product or parts of the system have to be rebuilt after every change in the source. In order to perform system building properly, we consider and check whether all components that make up the system been included in the build instructions, such as, include paths are set or not and whether all required tools for the development process are available and have the right version. In addition, all the reports associated with building, release and bill of the materials used, will be kept appropriately Version Control A version is an instance of the system component, which in some way differs from other instances. For our project, versioning includes new functionality that is added to a system component, for instance, any functionality that is added to OCR and TTS components. In addition, it applies to any identifiable unit, such as individual files that we created, libraries, executables, packages, etc. All the versions of any components of the system will be managed and kept properly with the usage of CVS. 3.3 CONFIGURATION STATUS ACCOUNTING CSA helps to provide a better picture of the project s true process. We will use the CSA in order to inform all the team members, our assistant and teachers about the status of the project. As for now, we are preparing reports that include the tasks completed for each week and the status of the project, and we present this status report to our assistant at the 7

8 meetings conducted every week. We assign each team member individually or as a group of two, a predetermined set of tasks to complete for every week and every team member is responsible with preparing her tasks status report. These all synchronize the activities of the team members. We will provide change request reports each time a change is approved for any component of the system. In addition, a configuration status report is generated on a regular basis for every building process and each defect detected. These reports will be placed in the web site of our project team. The following information will be prepared to account accurately for a configuration item's status that may have faced with any defect or change: A description of each configuration item that has been completed The time at which a component of the system is completed The time at which each change for a configuration item is performed The description of each software change The information of each defect detected 3.4 AUDITING The Software Configuration Audit (SCA) helps to ensure that changes have been properly implemented. We do auditing continuously, and we will do it with increased frequency and detail as development progresses. In order to ensure that changes are implemented according to the procedure defined in part 3.2.1, it is necessary to conduct Formal Technical Reviews (FTR) and SCAs. FTR focuses on the technical correctness of the configuration item that has been modified and SCA complements the technical reviews by accessing the configuration items characteristics that are usually not considered during the reviews. We will answer, how the requested change has been made, whether the change is technically correct or not, and whether all related configuration items are updated, during the audits. We will perform functional configuration audit on the software configuration items when the functional tests related to these items have been completed. The results of the tests will be checked for completeness and accuracy. Physical Configuration Audit (PCA) will be performed to verify that the software product conforms its technical documentation including its operation. PCA will be completed in concern with the environment tests. The results of the tests will be checked for completeness and accuracy. 8

9 4. PROJECT SCHEDULES AND CM MILESTONES To identify the required coordination of CM activities with the other activities in the project we configure the schedule information as absolute dates. Dates are arranged relative to other project activities, as project milestones, or as a simple sequence of events. Each task is assigned to group members considering the hardness of the task. Implementation of OCR, TTS, Screen Reader, user interface with integration, testing and packaging of the project are milestones of the project. These main tasks are subdivided into subtasks and each subtask is assigned to one or more people. MS Project is used to control the schedule of the project. In order to finish the project on time, project members try to be stick to the deadlines. If any changes occur in the deadlines, we note them and we cut the days from other tasks to adhere to deadline of the project. 5. PROJECT RESOURCES To make CM activities it is necessary to have some tools, techniques, equipments, and training. The main tool supported to use is CVS, which is mentioned above. The techniques are SCM tasks and the documents we have written before with the upcoming source codes will equip us to perform configuration tasks. Finally, the personnel is an important resource, who are simply the team members, the organization of which is described above. 6. PLAN OPTIMIZATION In this section, the activities and responsibilities necessary to guarantee the continuous software configuration management planning throughout the life cycle of the project will be identified and described. Nur Koç will be responsible for monitoring the SCM Plan and CM as mentioned in organization and responsibilities section. In addition, the two configuration sub teams will greatly simplify the management progress. The updates will be applied each week since we have weekly progresses. After changes are set and approved in sub teams, they will be discussed in weekly meetings among all team members. After the approvals, all the updates will be performed and related library will be constructed. In addition, in the weekly meetings the changes to the SCM plan will be updated and evaluated. After approval of these changes, they will be applied to the plan. 9

10 APPENDIX CVS version identification scheme Version ::= configurationitemname. versionidentifier versionidentifier ::= branch. revision branch ::= versionidentifier. branchnumber branchnumber branchnumber ::= nonnegativeinteger revision ::= nonnegativeinteger 10