CONFIGURATION

MANAGEMENT REPORT

for

BRAIN BASED

CONCANTRATION

ENHANCEMENT SYSTEM

M I N D E R

C E N G 4 2 9

L e v e n t B a y ı n d ı r

3 / 1 8 / 2 0 1 1

by MENTALLIGENT

Berk ESEROL 1534908

Evin ASLAN 1559921

İrem Gökçe AYDIN 1550268

Üstün YILDIRIM 1629419

Table of Contents

1. INTRODUCTION

1.1. Purpose of Configuration Management Plan

1.2. Scope of the Document

1.3. Definitions, Acronyms and Abbreviations

1.4. Document References

1.5. Document Overview

2. The Organizations CM Framework

2.1. Organization

2.2. Responsibilities

2.3. Tools and Infrastructure

3. Configuration Management Process In this part of the SCM report, the activities information will identify all functions and tasks required

to manage the configuration of the software system as specified in the scope of our previous plan

reports.

3.1. Identification To describe the documented physical and functional characteristics of the code, specifications,

design, and data elements to be controlled for the project we can slightly sum up our project.

Because of the fact that we use a brain-computer interface device(BCID), all the characteristics of

controlled items are based on the device output which is brainwave data. And the final outputs

development process are the concentration data set of the final user which is got through an

application designed by us. To identify the project configuration items (CI) and their structures at

each project control point, we divided our hierarchy six main CIs as mentioned in the following

source code part.

3.1.1. Source Code

The followings are the codes that are completed in implementation. If some changes and

reorganization in the design of the code components are needed, then the content of the will be

reconsidered in our project development project.

Manager Component:

As expected from many software development processes some kind of changes in the design of

implementation is common, still we have tried to stick to our design planned in the previous SDD

reports when establishing all the distinct boundaries between components in a more determined

way. In this component we have simply initiated the Login, GUI and BCID component and created the

necessary functions to communicate GUI class with BCID class. Because at the first stage of project

our aim was to be able to see the data coming from the device visually on the interface. However

one change in the implementation was instead of calling the Game component from the Manager

component according to the needed calling from GUI, we have called Game directly from the GUI

code. The reason for this will be explained in the Game Component part.

The followings describe the activities performed by this component in the source code:

The event that creates the baseline : main(), updateConcentrationMeter() called from GUI

component and getConcentrationData() called from BCID component.

The items that are to be controlled in the baseline : They are the band brainwave data

extracted from the device to be sent to GUI component and instances from Login, GUI and

BCID classes to activate them.

The procedures used to establish and change the baseline : We have first created all the tabs

and visual elements in the GUI side and Login side, created the necessary class definition and

methods in the BCID class to communicate them with the Manager Component.

BCID Component:

In this component we have simply implemented the methods to extracting the brainwave data from

the device channels and make them accessible in an array like structure to use by the Manager and

so GUI component to represent the user. The Epoc library provided by the company is mainly used in

this component.

The event that creates the baseline : informEEGBandDataUpdate()to extract the EEG band-

data from the device, getInstantConcentrationData() to get the average concentration value

from the channels data.

The items that are to be controlled in the baseline : EEGSampleBandData data type is used

from the Epoc library and stored in a double array.

AI Component:

This component has not been implemented yet. Because this next level decision part will be coded

after extracting the concentration data will be represented straightly and time-based. Moreover, the

changes in the Manager, GUI and Game components will directly affect this component so we are

proceeding cautiously not to go over the same source code over and over again.

Game Component:

In the source code of this component we planned simply to call the Flash game and affect the game

according to the coming concentration data from Manager class. By this way the user could see the

reflect of her concentration status over the game application. However, in the implementation

process, to make the flash swf ile on a Java GUI application we have used a Browser type variable. In

this variable the html file in which the swf file is called has been used. The source code of this process

was short so there was no need to create a Game class for only “showing the SWF file” on a GUI tab

purpose. So, instead of Game class, we embedded these calling SWF definitions in the GUI

component class. Neverthless, we will create the Game class and put these definitions/declerations

back to it because of the reason that we will show the effect of concentration data over the game via

a Flash-Java communication implementation.

For Flash-Java communication, we had found a JavaScriptFlash Proxy source code to access

ActionScript functions in the file to change, however some version and link problems have been

occured. So we have decided to use a new way, which is a kind of Socket Programming. In fact,

considering these cases, we will have to create a seperate the Game Class anyway.

Login Component:

Login Component source code simply a Shell type based text and button interface generator Java

class. In fact, the data filling in this interface will be checked from the database in the final product.

This confirmation process will be handled through Manager Component with Database part.

GUI Component:

In the implementation process, we mainly developed the source code of this component and

manager component up to now. In the GUI class code, we simply establish a communication with

Manager Component to get the instant concentration data. This data and Flash game component are

visualized by some Tab,Chart and Progress Bar kind of elements. Because the coming concentration

data information was so varied in only one second, because we had displayed all the values gathered

from the device instantly, we have made a bit of change in the implementation. We have calculated

the average value of the Beta brainwave data to use for any need from now on. So the user now can

see the increase and decrease in his/her concentration value in a more observable way.

3.1.2. Data

The configuration items to be controlled are mainly the instant concentration data that is

extracted from the device by BCID class component. The other data on which the GUI class and Game

Class make changes is the Flash Game data which is created as ActionScript file. Moreover, the login

information data filled by the user is the data to be placed in the database and checked for accessing

out system. Their definitions and types are declared in the previous detailed design report.

3.1.3. Documentation

The documents have been prepared for configuration control. All the Software Requirement

Report, Software Description Desing Report and Detailed Design Report are shared with our assistant

via a project management system : ubiself.basecamphq.com with name Mentalligent in the first

term. This account was created by our assistant, Levent Bayındır. Moreover, the same files were

shared with the sponsored company, Minder, via google groups with the url :

http://groups.google.com/group/mentalligent. Besides from technical documentation sharing

between the company and the department under the course frame, we have created a blog in which

there are lots of background information about our project baseline ideas and cognitive science

which we are dealing with in our project. In this blog which is accessble by any user,

http://www.mentalligent.blogspot.com/, we have also included the project development process

details and all the problems that we have encountered in this process. We update all the documents

and necessary information sources regularly through these ways.

3.2. Configuration Management and Control In the management of the software some implementation changes have been occured as

mentioned previously between the Game class and GUI class. Moreover, at the beggining of the

implementation we have encountered some problems related to the library which was provided by

Minder. The problems were about the connection status of the device, the imbalance between the

size and time of the extracted brainwave data which was sampled and stored and array structure,

unnecessarily kept log file of the sampled band data, the efficiency constraint of the functionality of

the threads that deal with FFT transformations of brainwaves. All these requests for changes were

informed to the advisors in Minder Technology. These changes have encompassed both error

correction and enhancement of the system. So, the company have released a new version of the

library to be used by us. The problems that could be handled have been dealed with. We are now

moving further with this new version of the library. So, in the configuration management when we

face some problems we have got together and tried to find the best solution and then applied it.

3.3. Configuration Status Accounting The configuration status accounting activities record ans report the status of the project

configuration items. So, in our project the data elements ans SCM metrices are to be tracked and

reported for baselines and changes are the instantly extracted brainwave sampled data. We have

made changes on them as taking the average of them for an specific time interval to make them

observable. The other elements are in the visual part of the system like showing the Game

Component and the tabs like elements. The status accounting reports are generated weekly to give a

feedback to our course assistant. Moreover, the company are informed by the status of the project

regularly via some e-mails and demo representations. They generally have approved our approach to

the implementation desing and support us while making changes. Our information is collected,

stored, processed and protected from loss via the subversion system of Eclipse itselt. We have had

an account from XP-Dev to serve as a repository for subversion purpose. So, we have back-ups and

versions of our project int this system and we all proceed coding over the project in this svn system.

If any crashes will occur, there would be no need to worry abour the loss, because ther would be no

“loss” actually. Besides, our department has served a subversion service under

senior.ceng.metu.edu.tr/2011/mentalligent. Apart from the SVN system, while we code, we try to be

careful about the keeping the meaning of the functions and their service. We’re making this control

by using comments through the code. So, it becomes easy to track the data or changes in data for

other group members.

approved changes.

3.4. Auditing The evaluation by the audits to determine the extent to which the actual configuration items

reflect the required physical and funtional characteristics is really important for uz, for every

software developer. Because our products are developed for the purpose of serving the end-user,

the auditing is an essential issue. As a project group, we get together regularly and brain-storm about

the status of the project and what is needed for improving it. Because some little changes, for

example in the interface part, should be examined for the potential effects on the project. So, we

generally try to move determined and make only little changes on the system. Apart from ourselves,

our project assistant is an audits on the process of our implementations. The vendor auditing part of

our project is the sponsored company, Minder. They support us in a way that they incorporate items

developed outside the project environment. And they give special attention directed to the SCM

activities to go further more quickly and more substantial.

The external code which is the Epoc Library and device SDK’s have been provided us and the

have updated the library again because of some problems. While doing these changes, obviously

they test the library and after deciding its varification, the library have been merged to our system

again. After these changes, the company has wanted us to give them a feedback about the new

version of the system and we tested it in our machines too.

Besides of talking about the auditing speeches and their approaches, there are some proprietary

items to be handled for the security of information and traceability of the ownership. We will create

a secure database system with some kind of encoding to set the privacy of our end-users.

4. Project Schedules and CM Milestones

5. Project Resources

6. Plan Optimization