IEEE Paper Template in A4 (V1)

weaverchurchΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 11 μήνες)

190 εμφανίσεις

Team Matrix Project Report

Kelly Kemnitz, Khanh Hoang,
Mulya Nugroho


CS 680 Intro
duction to Software Engineering
,

Wichita State University

1845 Fairmount St
.

Wichita, KS 67280 United States

kgkemnitz@wi
c
hita.edu

kxhoang@wichita.edu

mxnugroho@wichita.edu


Ab
s
tract


This report
documents the process

that
Team Matrix

we
nt through to build the Automated

Storage Array
Configuration Tool. This application
assists test engineers and contractors

by automating the process of
storage array
configuration required for

test setups.


I.

INCEPTION PHASE

A.

Requirements

After
brainstorming on the project idea, we decided to go with Kelly’s. We
sat

together and
discussed

what we as customers
would like the project application to do
.
We arrived at the following requirements:



The
application should all
ow users to create volume group(
s
)

of

various redundancy levels, with a

specified number of
drives.



The user

must be able to create volume(s)

of different

capacity.



The user

must be able

to create secure volume group(s) if encrypted d
rives are present within the storage array
.



The user

must be able to en
able data protection on volume(
s
)

if applicable drives are present
.



Th
e user

must be able

to create volume copies of a volume(s).



The user must be able to create point
-
in
-
time snapshot
volume(s), if such premium features are enabled on the storage
array
.



The users must be able to map volumes to
hosts for data usage
.



The
application

should support different OEMs/customers
.

B.

User Stories

Based on
requirements we gathered and generated ourse
lves
,
the following user stories were developed prior to Iteration I.



Create volume groups

The user should be able to create multiple volume groups.



Create new volumes


The use
r must be able to create volume
s
of varying

capacity.



Create volumes in existing

volume groups

The user must be able to create volumes in
an already present volume group
.



Pick different RAID levels

The user must be able to choose different disk redundancy level when creating a volume group.



Select number of drives

The user must be abl
e to
select

the number of drives in a volume group.



Volume size

The user must be able to
modify volume capacity
.



Create volume copies

The user must be able to create
copies of volumes,

if the feature is enabled on the storage array.



Create snapshot volumes

The user must be able to create a point
-
in
-
time snapshot of volumes
,

if the feature is enabled on the storage array.



Management IP address

The user must be able to manage a storage array via
controller IP addresses
.



Rename array

The user must be able to r
ename the storage array.



Obtain array information

The user must be able to obtain storage array information
, including

the number of volumes present, the number of
unassigned drives, etc.



Obtain logs

The user must be able to obtain
logging information from

the storage array
.



Enable data protection

The user must be able to enable
the
data protection feature on capable volumes.



Secure volumes

The user must be able to create secure volume groups using secure
-
capable

drives.



Host mapping

The user must be able
to map volumes to any host connected to the storage array.



Change cache setting

The user must be able to change the cache setting
s on a volume
.



OEM coverage

The application must be able to add and manage
storage arrays branded for any customer.


TABLE

I

USER STORIES ESTIMAT
ION AND ASSUMPTIONS

User Stories

Estimation

(Days)

Assumptions

Create volume groups

1

One of the first user stories that we need to implement.

Create new volumes

1

Follows the creation of new volume groups.

Create volumes in
existing volume groups

5

May be somewhat difficult, as we need to see what volume groups exist and store
that information.

Pick different RAID
levels

1

Fundamental element of volume group creation.

Select number of drives

3

Will have to

export the number of drives and available capacity, which may take
some time.

Create volume copies

1

Premium feature, but we need to verify that the user is not trying to make a copy of a
volume that does not exist.

Management IP
addresses

3

Must store
this information in a class, to use for all methods

Obtain array
information

2

Can be used to provide information about number of drives, volume groups,
volumes, etc. that are available.

Enable data protection

1

Another premium feature, which should be
fairly simple to implement.

Host mapping

2

Will need to figure out what hosts may already be available, and whether they
exceed mapping limitations.

Volume size

2

Required for volume creation, so definitely necessary.

Create snapshots

1

Premium feature,

but once again may need to acquire information about the storage
array.

Rename array

1

Should be a fairly simple task.

Obtain logs

6

Will need to store the information somewhere, so this may take some time.

Secure volumes

1

Premium feature which can be

enabled fairly easily

Change cache settings

2

Basic element of volume, but can be done without much difficulty.

OEM coverage

3

This involves changing of paths and command line options, so this may take some
time.


36



C.

Iteration Plan

Iteration 1

User
stories:

-

Create volume groups

-

Create new volumes

-

Create volumes in existing volume groups

-

Pick different RAID levels

-

Select number of drives

-

Management IP address

-

Obtain array information

-

Volume size

-

OEM coverage


Total days: 19

With velo
city: 30

Divided by 3 members: 10


Other activities:

-

Create UML diagrams

-

Create initial GUI

-

Setup SVN


Iteration 2

User stories:

-

Create volume copies

-

Enable data protection

-

Host mapping

-

Create snapshots

-

Secure volumes

-

Change cache setting


Total days: 14

With velocity: 20

Divided by 3 members: 7


Other activities:

-

Create new GUI using netbean

-

Work on networking part of the program, telnet and ftp


Iteration 3

User stories:

-

Rename array

-

Obtain logs


Total days: 3

With velocity: 4

Di
vided by 3 members: 1


II.

DESIGN

PHASE


After
developed

user stories

and
the overall
iteration plan,
we proceeded

to
the
design phase and created the following
diagrams
:

A.

Use Cases

We answered the following questions
while

developing the use cases
:


Q:

What are we building?

A:

An application to assist in configuration management within a testing environment. Creating a testing environment
often involves either performing various steps manually, whether by user
-
interaction or scripting. The goal is to au
tomate
this process with a hands
-
free approach, enabling users to bypass previous methods and interact with the storage array
via the application.


Q:

Who will be using?

A:

Software test engineers and contractors


Q:

What else will be used that you are not

building?

A:

The application will utilize command line interface commands previously developed and available within host
software applications, which allow an actual interface to the storage array.


Q:

Who is the primary actor?

A:

Software tester


Q:

Who
will start and stop the application?

A:

Primary actor


Q:

Who gets notified when there are errors or failures?

A:

Primary actor


We then created the goals that the primary actors want to accomplish by using our application



Create volume groups: The
software tester wishes to create a volume group on the storage array. The software tester
utilizes the Configuration Creation Tool to assist with this task. The application presents the tester with fields to
enter the controller management IP addresses. Th
e tester enters this information, and adds the storage array to the
application. The tester can then create a volume group, utilizing a step
-
by
-
step method. The storage array will now
have a new volume group, which can be used in the future for volume crea
tion.



Create new volumes: The software tester has previously created a volume group, and wishes to now create one or
more volumes within the volume group. The management IP addresses have been entered to successfully manage the
storage array, and the user
can create a volume with a user
-
specified name and capacity within a volume group.
Upon completion, one or more volumes will be present within the volume group and available for use.



Obtain information: Basic information about the existing configuration of

a storage array is often needed prior to
setup. The software tester can utilize features of the application to obtain information. The software tester will enter
the management IP addresses of the storage array and add it to the application. A summary pag
e will be displayed
after the completion of this task, which provides such details to the user.



Modify volume size: A software tester may need to increase the overall size of a volume. Using the application,
he/she enters the volume identifier that require
s capacity modification. Depending on the size specified, the storage
array may require additional time to complete the task re
-
configuring the volume's applicable space within volume
groups of differing redundancies.



Create volume copies: A test may requi
re the creation of exact copies of a volume. The tester uses the system to
create volume copies of a volume specified within the application. The number of copies to create is also specified
by the user.



Enable data protection: During the creation of a vol
ume group, the software tester specifies that the volume group is
DA (Data Assurance) capable. At any time, the tester may wish to enable data protection on a volume within a DA
-
capable volume group. The tester chooses to do so, and data protection is now
enabled on a specified volume.



Create host mappings: The software tester has created all the required volume groups and volumes necessary for a
testing environment. The volumes must now be mapped to a host to provide a host with additional storage. The
sys
tem presents the capability to perform this task to the software tester, and volumes become mapped to a host. The
software tester can now access additional storage devices (logical units) on hosts installed with any operating system.



Create snapshots: A te
st may require that point
-
in
-
time snapshots of one or more volumes are available. The
software tester enters the volume that he/she would like to create snapshots of, and the application creates these
images.



Create secure volumes: The software tester need
s to enable encryption on volumes. The tester utilizes the application
to secure any number of specified volumes. The application executes commands via a command line interface to
enable volume
-
level feature on the storage array. The application finishes t
he task and the tester now has secure
volumes available to him/her.



Volume cache settings: Changes to cache setting parameters are needed prior to test. The software tester enters the
volume(s) that need such modifications into the application, and the app
lication communicates with the storage array
to complete the task. The tester now has volumes of varying cache settings available, as does the host any such
volumes are mapped to.



Rename storage array: The tester hopes to rename the storage array for ident
ification purposes, as he/she manages a
large number of arrays. Using the application, the user enters in the management IP addresses of the storage array, as
well as a new name for it. The application performs the renaming task, and the tester can now acc
ess the storage
array in other software with the new name.



Clear information: The tester wishes to start an automated test to run over the weekend. Prior to beginning the test,
previous logging information on the storage array needs to be cleared so that e
rrors encountered during the testing
timeframe are easily detectable. The tester enters the management IP addresses into the application and selects the
option to clear storage array logs. The application talks with the storage array and executes delete co
mmands. The
tester now has an empty log to begin testing.



Fig. 1
Use Cases Diagram

B.

Class Diagram

Figure 2
presented the class diagram that we created



Fig. 2 Clas
s Diagram

C.

Sequence Diagram

Figure 3 is the sequence diagram for
task of creating a
volume.


Fig. 3 Sequence

Diagram

III.

C
OMPILATION AND
E
XECUTION

A.

Subversion

The final code for our project can be found at the following URL:

http://kellykemnitz.com/svn/CS680/Final


The code for all itera
tions can be found at the following address:

http://kellykemnitz.com/svn/CS680/


B.

Executing the Application

To execute the application, the code must be retrieved from SVN and
compiled using the Eclipse IDE. However, it is
preferred that the application be run within the NetApp network environment, as the program is coded to connect to an
intermediary host to execute storage array commands.


IV.

P
ROJECT
D
EVELOPMENT

Initially, we dec
ided to divide the project into multiple iterations, with the first iteration having the most basic functionalities
of the application.

Our primary struggle with the application dealt with GUI programming, as we had not taken on such a task in any previou
s
coursework. We utilized the Eclipse IDE for our initial attempts of developing a graphical user interface, but this proved fu
tile
due to the lack of finishing touches the development tool provides. Simple internet queries allowed us to discover the usefu
lness
of NetBeans, which provides drag
-
and
-
drop functionality in unison with coding. However, we still encountered difficulties with
the passing of parameters from the GUI to the underlying methods used by the program. Such instances included the use of a
checkbox for volume group creation. Such difficulties resulted in us failing to meet our initial deadlines set for Iteration
I, as we
only completed six of eight user stories and were still completing Iteration I tasks beyond the anticipated timeframe.

The

second iteration included network functionalities, as well as tasks such as the checkbox problem we faced throughout
Iteration I. We were able to complete
some of the core communication methods using the Telnet application, but failed to
complete tasks in
volving FTP. Out of the six user stories, we unfortunately were only able to complete two due to time
constraints and aforementioned issues.



Fig. 4 Main Window


Fig. 5 Volume Group Features

V.

T
EAM
C
ONTRIBUTION
M
ATRIX


Tasks

Khanh

Kelly

Mulya

User
Stories

33.33%

We all work
together to
come up with
the user
stories

33.33%

33.33%

Iteration
Planning

33.33%

We all work
together to
come up with
the iteration
planning

33.33%

33.33%

UML Class
Diagrams

70%

Came up with
the initial
diagram

15%

Work togeth
er
with Mulya
reviewing and
revising the
first diagram

15%

UML
Sequence
Diagrams

70%

Came up with
the initial
diagram

15%

Work together
with Mulya

Reviewing and
revising the
first diagram

15%

Use cases

10%

Reviewing
and revising
the use cases
and use
case
diagram

40%

Came up with
the initial use
cases.

Reviewing and
revising the
40%

Came up with
the initial use
case diagram.

Reviewing and
revising use
diagram.

cases.

Code

50%

Generate code
for main
functionalities.

Create initial
GUI.

15%

Set up SVN
server.

Helped with
troubleshooting
code.



35%

Enhance and
generate code
for GUI.

Assist Khanh
with
troubleshooting
the code.


Power point

35%

Formatting
and styling the
slides. Create
video.

30%

Adding input
and reviewing
the slides.

35%

Came up with
ro
ugh draft of
the slides.

Project report

35%

Formatting the
report.

30%

Adding input
and reviewing.

35%

Came up with
rough draft.

Final
presentation

33.33%

We divided
the
presentation
equally.

33.33%

33.33%