SmARt Shopping Project

Size: px
Start display at page:

Download "SmARt Shopping Project"

Transcription

1 Configuration Management Plan SmARt Shopping Project Sponsored by ASELSAN V1, 2010

2 Table of Contents 1. Introduction Purpose of Configuration Management Plan Scope of the Document Definitions, Acronyms and Abbreviations Document References Document Overview The Organizations CM Framework Organization Responsibilities Tools and Infrastructure Configuration Management Process Identification Source Code Data Documentation Configuration Management and Control System Change Requests(SCR) System Change Evaluation System Change Implementation Configuration Status Accounting Auditing Project Schedules and CM Milestones Project Resources Plan Optimization

3 1. Introduction 1.1. Purpose of Configuration Management Plan Configuration management refers to managing a relative arrangement of parts or elements, and it is a well known fact that while parts or elements in a system increases in number, it gets harder to manage them and their relations between them. In terms of a project, these parts can be thought as classes, modules, and implementations and managing them can be difficult in complex projects. Additionally, in the process of developing a project, these parts, namely classes, modules and implementations, changes in order to fulfill needs arising from improvements of the project and the problems faced while implementing. These changes may occur at any time and also may occur simultaneously. In order to be able able to manage the project, to deal with these changes in a professional way, to ensure that there is a safe communication between developers, and to improve the quality of the application and its reports, managing a relative arrangement of parts, in other words a configuration management plan is essential for a healthy project improvement process. Since SmARt Shopping Project is a complex project which consist of several communicating components, and several data objects under a interactively changing interface, it is necessary for our team to build a configuration management plan in order to carry this project forward. This Configuration Management Plan (CMP) aims to specify the details of the team work working on SmARt Shopping Project and to help our team in providing the stability of the design and implementation of the project Scope of the Document The scope of this document is the SmARt Shopping Project, conducted by Pi and sponsored by ASELSAN. This document consist of information about organization of the team, responsibilities of the team members regarding this project, timeline, and CM activities that are to be applied. Identifying components, and the structure, controlling releases and changes, recording, logging and reporting status, and finally validating completeness, and the way how these actions are performed is mentioned in this report. The intended audience of this document is the developer team, Pi, the 2

4 sponsor company, ASELSAN, and the instructors responsible for CENG492 course at Computer Engineering Department of Middle East Technical University Definitions, Acronyms and Abbreviations CM : Configuration Management CMP: Configuration Management Plan CCB: Configuration Control Board CCT: Change Control Team CMT: Configuration Management Team CI: Configuration Item SCR: System Change Request SDT: Software Development Team TT: Testing Team VCT: Version Control Team CENG: Computer Engineering SVN: Subversion, a software versioning and a revision control system TRAC: an open source, web-based project management and bug-tracking tool. Eclipse: Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. Our project uses Eclipse CDT for C/C++ projects. Eclipse CDT: The CDT provides a fully functional C and C++ Integrated Development Environment based on the Eclipse platform. IEEE: The Institute of Electrical and Electronics Engineers 3

5 1.4. Document References [1] [2] [3] [4] [5] Pressman, Roger S. Software Engineering: A Practitioners Approach McGraw-Hil, 2001 Watts, Frank B. Configuration Management : Product Lifecycle and Engineering Documentation Control Measurements Oxford, 2010 Hass, Anne M.J. Configuration Management Principles and Practice Pearson, 2003 Configuration Management, The presentation prepared by CENG492 instructors IEEE Standard for Software Configuration Management Plans (IEEE Std ) 1.5 Document Overview This document consist of six sections, namely Introduction, The Organizations CM Framework, Configuration Management Process, Project Schedules and CM Milestones, Project Resources, and Plan Optimization. In the first section, the purpose of the CMP, the scope of the document, the acronyms that are used are explained, and documents that are referenced are included. In the second section, The Organization CM Framework, the organization of the team, the tools that are to be used and their function in this project, responsibilities of team member are presented. In the third section, Configuration Management Process, the identification of the configuration items, the methodologies that are to be followed, and the plan for the audits are subparts are explained. 4

6 In the fourth section, Project Schedules and CM Milestones, important dates and milestones are listed. In the fifth section, Project Resources, the project resources that are needed for CM is defined. Finally, in the sixth section, Plan Optimization, the way that our team chooses to optimize the CMP is explained. 2. The Organizations CM Framework 2.1. Organization Pi has four members and each member has equal rights on the project management process. in order to have a qualified and successful project, all of the team members take part in the CM. As a result the members shared different tasks and arranged sub-teams which have different missions. The sub-teams and their tasks are explained below: Software Development Team (SDT) The main responsibility of SDT is to implement the modules of the SmARt Shopping project. Moreover, when the testing team (TT) requests changes, they are made by SDT. This team has other responsibilities such as fixing bugs, creating releases and updating the source code via SVN. Configuration Management Team (CMT) The main responsibility of CMT is to maintain the organization of CM. In order to sustain the organization, CMT keeps the plan up-to-date. Change Control Team (CCT) The main responsibility of CCT is to accept or reject SCR s, to review SCR s and to monitor SCR s. Furthermore, this team supervises all the activities of the other groups. 5

7 Testing Team (TT) The main responsibility of TT is to find bugs in the system and to control adequacy of the modules. If the requirements are not fulfilled, this team may want to change requests. After testing, this team gives feedback about the modules. Version Control Team (VCT) The main responsibility of VCT is to monitor the versions of Smart Shopping Project and to merge different branches Responsibilities Although team members have different responsibilities in different sub-teams namely SDT, CMT, CCT, TT and VCT as explained in Section 2.1, all the members of Pi take part in Configuration Control Board (CCB) so they share same individual responsibilities. Those responsibilities include : When a change is made on the source code by a member, it should be commented before it s put into repository through SVN. Each member should follow the pre-defined CM schedule. Other members should be informed about SCR via Tools and Infrastructure Eclipse CDT Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. We will use Eclipse CDT platform for C/C++ project because it s a developer friendly environment and provides a good support to combine different parts of our project. SVN (Subversion) Subversion (SVN) is a file-level version control system that permits many types of organizations to work on several project versions at the same time. This capability is particularly 6

8 beneficial in a software development environment, where it is used in maintaining parallel code versions. SVN is used to maintain current and historical versions of files such as source code, web pages, and documentation. In our project, we will use Eclipse s plug-in (Subclipse) to commit or update the source code. TRAC Trac is an open source, web-based project management and bug-tracking tool. It also serves as a web interface to a revision control system, in our case SVN. WebPage our web page. All of the documents, information about the project and the project progress can be seen on Google Docs Easy-to-use online word processor, spreadsheet and presentation editor that enables you and your team to create, store and share whole the project documents. 3. Configuration Management Process 3.1. Identification The Configuration Items (CI) can be separated into 3 categories namely source code, data and documentation will be explained in detail in the following sections : 7

9 3.1.1.Source Code We can divide our source code into two parts, since we continue coding in two different sides. First part can be thought as the image processing part. With using OpenCV libraries, we do the object recognition and labeling operations. However, our design changes according to some considerations. For example, since our project is an augmented reality project, time is an important concern for us, which affects the algorithms we implement and as a result our source code changes. Moreover, we apply tests like whether the pre-defined features are detected in the video frame in adequate distance. If tests fail, again we need to modify our source code. Second part is the user interface part, whose design and source code has changed in time according to the new facilities and sections added to the project. With the decisions of all team members and their agreement, the design of the user interface has its final version but its design and source code may change again, if improvement is necessary Data In Smart Shopping project, data consists of visual data which is coming from the camera, and the known data that is kept in the database. Visual data is temporary, when the operations are completed, they are gone, so they are not saved. However,the features of the objects that are desired to be recognized from the video frame and the general information about those objects like their names, prices etc. are the parts of the data that are kept in the database Documentation All documents are written with the contribution of all team members and most of them can be found in our website. The documents written so far includes: Project Proposal Software Requirements Specifications 8

10 Initial Design Report Detailed Design Report Configuration Management Plan Weekly Reports 3.2. Configuration Management and Control System Change Requests(SCR) During our project, minor System Change Requests will directly be handled by SVN and they will not require extra information. However, major System Change Requests will be controlled by the Trac system. Such System Change Requests will consist of: name of the related team member description of the System Change Request date of the System Change Request possible deadline of the System Change Request related system module of the System Change Request priority of the System Change Request version of the System Change Request. When any team member reported a System Change Request, Trac system opens a ticket and it can be seen by every member System Change Evaluation The main discussions about the evaluation of the SCR are done by tickets in the Trac System and their logs are kept. However, also in the face to face meetings, the evaluation process of the 9

11 SCR s are discussed. Members can give opinion about the SCR and the best way of evaluation will be determined System Change Implementation When an SCR occurred after an evaluation, it can possibly effect other related CI s. In such condition, those CI s will be determined and changes are applied to them. Then, they can be updated through SVN. 3.3 Configuration Status Accounting In the previous sections, configuration items are introduced. In the project, information about related configuration items are needed to be stored because, when there are more changes, it gets harder to control every configuration item. In the project, keeping the track of development process is essential and in order to achieve this important goal, different ways will be used to express those changes and updates simultaneously. In this way, both the project members and the other people who are following our project can be communicated. The information will consist configuration identifications, change the information of request and information about the details of the implementation. While approaching to the end, comments of the SVN commits and meeting reports will guide us through the common changes. Also, versioning of the project will be controlled by comments and defining the use of updates. Finally, information about the development process of the project and the problems and their solutions will be published by the web page of the team. 3.4 Auditing Auditing will be done by all members of the team. Changes that are made on a CI will be checked during the auditing phase. Auditing of the code will be done weekly by using appropriate test methods. Also, each team member should check his/her own part of the code to determine its correctness. Each member can commit that code to SVN after self-checking. 10

12 Also, before the commit, each member should make sure that code has compiled and working properly. By checking this and committing the code after this test, team can be sure that the project that is kept in the SVN can be compiled and working correctly. Project schedule should be checked and updated regularly in order to obey the timing that is planned. 4. Project Schedules and CM Milestones Our project milestones are designed according to the restrictions in the course syllabus and the pre-defined dates previously defined in initial design and detailed design report. Since in our project we use many units concurrently, it also effects our due dates. We started every step with wide literature research in order to decide which technologies we are going to use and how we are going to implement the coding in the direction of our purposes. After all these decision helper step we move on with installing, testing and being familiar with these different units such as OpenCV, Qt, SURF, FAST etc. After that we start the coding and testing parts. Therefore, all the milestones are decided according to these restrictions. Here below, there are some important milestones. Project Milestones Dates (DD / MM / YYYY) Web Page Publish 24 / 03 / 2011 Committing the code to SVN 30 / 03 / 2011 Implementation of SURF 30 / 03 / 2011 Living Schedule 31 / 03 / 2011 Integration of Units and Testing 1 02 / 04 /

13 First Development Snapshot 06 / 04 / 2011 Implementation of Database 12 / 04 / 2011 Integration of Units and Testing 2 15 / 04 / 2011 Test Specification Report 22 / 04 / 2011 First Release / Demo 13 / 05 / 2011 Final Package / User Manual 15 / 06 / Project Resources Other then the team members of Pi, we have 5 subsidiary project resources which are: SVN : Revision Control System Eclipse : Development Environment Web Site : Project Development News Google Docs : Report Sharing and Editing Environment TRAC : Issue Tracking System 6. Plan Optimization Configuration Management Report is supposed to be a guide for both configuration and progress of the project smart shopping. Configuration Control Board is going to be control all the updates and changes in this report. If any change or update comes into this document, TRAC system will warn all the users. There will be weekly meetings among group members. According to these meetings, living schedule is going to be formed regularly and published in the web site of the group. By keeping the Configuration Report valid, we are able to monitor the development status while 12

14 working for the implementation. All of our group members are responsible for updating and editing this report. A plan optimization can be occur when an update occurs in this report. 13