fall2013-team14-Interim-second_report

1

NetApp Update Center

Interim Project Report

Sponsor Netapp

NetApp Sponsor Liaisons: Mr. Chuck Fouts & Dr. Clinton Knight

CSC492 Team #14:

Jason Brown

Santosh Beyagudem

Zack Litzsinger

Dylan Ventra

North Carolina State University Department of Computer Science

October 21st, 2013

2

Outline

1. Executive Summary

2. Problem Description

a. Sponsor Background

b. Problem Statement

c. Project Goals & Benefits d. Development Methodology

e. Challenges

3. Resources Needed

4. Requirements

5. Design

6. Implementation

7. Test Plan & Results

8. Suggestions for Future Teams

9. Task Plan (Written Interim Project Report only)

Required Separate Documents

Installation Guide

User Guide

Developer’s Guide

3

Executive Summary

The NetApp Snap Creator Framework is a tool that is utilized by a large number of high profile companies in order to do data storage and backup, thereby providing a safeguard from losing valuable data. The NetApp team has tasked our team with the development of an Update Center, which is intended to help validate compatibilities between various plugins and the primary Snap Creator components, the server and agent. Our solution will connect to the main Snap Creator framework and provide our functionality to the Snap Creator production system. Over the last couple of weeks we were able to get access to the NetApp Snap Creator Community and source code for the Snap Creator Framework through Git. We have been able to build and run the server and agent by using an installation document one of our NetApp contacts gave us. Recent development has primarily been focused on creating the Update Center in Ruby on Rails, specifically the database, the web API, and the graphical user interface. This development mirrors our designs that we created during the initial part of the project. We are using an agile development process utilizing Rally to track our iterations. Overall we are progressing at a steady rate and moving toward completion of the Update Center, as well as beginning to look at integration and setting up a build server. Our goal for the coming weeks is primarily to finalize the Update Center and put it onto a server that we can access by using a build server provided by NetApp. Integration is a must in the near future, as is better task planning since our current task planning has been weak at times.

4

Problem Description

Sponsor Background Our sponsor, Net App, has a local campus in Research Triangle Park in North Carolina, but their headquarters is located in Sunnyvale, California. The company focuses on network and cloud storage for large scale data, including virtualization and cloud computing. They are responsible for a significant portion of data storage and backup within major companies, including 85% of the Fortune 500. The project presented to us is to create a Snap Creator Version Update Center to help monitor server versions, agent versions, and plugin versions and help decide if upgrading the current version is compatible. This capability will allow customers to be able to update their systems based on their current plugins without having to worry about issues. Their primary motivation in giving us this project is to develop a solution for compatibility within their internal components to ensure that items properly communicate with each other and that the user knows which version of software to download. When we integrate our solution into their framework, they will have a smoother user experience in the maintenance and installation of their product.

Sponsor Contacts: Mr. Chuck Fouts [email protected] Dr. Clinton Knight Sr. Manager, Snap Creator Engineering [email protected]

Problem Statement NetApp’s Snap Creator product utilizes community developed plug-ins to interface with Snap Creator Agents which then communicate with the Snap Creator Servers. This 3-tier style of collaboration among software requires consistent compatibility and version monitoring. Plug-ins need to know which agents will support them as well as which other plug-ins are compatible while running on the same agents. When a server update is made, administrators need to know which agents need to be updated as well. Furthermore, if an Agent is upgraded, it will need to reference plug-in version information to check if it is still compatible with the new system.

Project Goals & Benefits In order to solve the problems addressed above, a Snap Creator Update Center must be developed. The Update Center will be a stand-alone server that will service requests from Snap Creator Plug-ins, Agents, and Servers.

5

Our goal is for the Update Center to maintain complete compatibility between all 3-tiers of the Snap Creator product. In order for the Update Center to accomplish this, we will also develop a versioning system for each of the applications. Databases need to be developed to store compatibility information for reference upon various Update Center server requests. Lastly, a web application will need to be developed for administrators to update the compatibility and versioning information on the Update Center. Since the Snap Creator product focuses on community driven development by allowing custom plug-ins to me made to interface with Snap Creator Agents, it is critical that compatibility be maintained. Otherwise it would be difficult for plug-in developer to know which agents they can access and for customers to know which plug-ins they can access for their particular agent and their currently installed plug-ins. Also, as new versions of both servers and agents are released by NetApp, developers need to know which version of the open source framework that they need to be building their plug-ins for.

Development Methodology We will be using an agile development process with iteration cycles of two weeks. Each iteration will be planned out on its initial date and completed with testing complete and a demo on Wednesday during our regularly scheduled meeting time. The thrust of our iterations will be primarily on identifying the problem and attempting to solve it a few days before the iteration is done so that testing can be completed for it. Coding will be done in pairs, with one person testing the component that the other builds. At the suggestion of our NetApp contacts, we will be using Rally to plan and manage our sprints with input from our sponsor contacts.

Challenges Technical Challenges

● Github: Repositories have been a big issue for us. It is important that we maintain repository for us to all add our individual contributions to this collaborative project. However, we have had issues keeping our own local copies in sync. To address this issue we started using branches for our own local directories and we merge them with the main branch.

● Ruby: Our Update Center server is running on Ruby on Rails. Our databases are also running the same platform. However, all of our team had no experience programming in this environment before. In order to learn Ruby on Rails we each followed online guides and tutorials. Then when we finished a few tasks we discussed with each other how we solved each task and explained how we did it with Ruby on Rails.

● Rally: We used Rally to document and plan our iterations. However during our first iteration we were very confused and ignorant to all that Rally had to offer. As a team we met with our NetApp sponsors and they walked us through how they use Rally. This gave us insight

6

into actual, production level, commercial iterative software development.

● Deploying Update Center Server: Our server will be deployed, maintained, and hosted by NetApp on their local VPN. Therefore we have limited control over setting our server up until NetApp provides it for us.

Legal Challenges ● NetApp’s Snap Creator product is open source and community driven

so we don’t have many legal challenges. However, since our server is being hosted on NetApp’s VPN, we will have a legal liability for what we do on their network.

Resources Needed

● We will need GitHub to host our repository as well as to collaborate with the current Snap Creator source code, as it is hosted on GitHub.

● During our development process, Rally will help us to plan, document, and track our process iteratively.

● Our Update Center will be created on a Ruby on Rails platform. As such, we will need Ruby and Ruby on Rails installed on our machines.

● Google documents is needed as a document repository and as a way to collaborate between team members.

● We also need NetApp to host our server using Jenkins to deploy the application.

Requirements

Overall View

● The system should have a release name to help identify it ● Provide a version management system for the Snap Creator Server,

Agent, and Plugins ● Create Snap Creator Update Center to determine which versions are

compatible with which components ● Ensure that the Snap Creator team can integrate our solution into a

production environment and expand on it

Detailed Requirements

Update Center Requirements

1. Functional 1.1 Update Center shall determine if a plugin is compatible with a given SC agent 1.2 Update Center shall determine if an agent is compatible with a given SC server

7

1.3 Update Center shall store versioning metadata for plugins that describes if it is compatible with a certain version of agent 1.4 Update Center shall store versioning metadata for agents that describes if it is compatible with a certain version of a server 1.5 Update Center shall allow admins to upload updated versions of files 1.6 Update Center shall a simple user interface that allows versioning metadata associated with plugins, servers, and agents to be managed 1.7 Update Center shall provide a way to set the initial admin password

2. Non-functional

2.1 Update Center must be available to the server through the local network and must accept web request calls that follow the specifications of the Update Center web API 2.2 Update Center must connect to the versioning framework created within the Snap Creator framework 2.4 Update Center shall ensure that all most recent versions of agents, servers, and plugins work together; if this is not the case, it will use the most recent versions that work together 2.5 In the result of an invalid database configuration or other unknown error, the Update Center shall not fail in a manner that prevents it from receiving other web requests 2.6 Update Center shall utilize a database with a schema to keep track of versioning and compatibility 2.7 Update Center shall require a login to manage the database 2.8 Get requests on the Update Center shall not require a login and shall not cause any modifications on the database

3. Constraints 3.1 Update Center must maintain 70% test coverage or greater.

3.2 Update Center must be created using a web framework that can be extensible and easily maintained by Snap Creator team after our development cycle.

8

3.3 Update Center shall utilize the existing SnapCreator method of downloading updated files rather than reimplementing a new system

Snap Creator Server Requirements

4. Functional 4.1 SC Server shall have the ability to poll a known URL for update meta-data related to the installed product. 4.2 SC Server shall provide the customer the ability be able to turn compatibility checking with the Update Center off from a configuration file. 4.3 The SC server GUI will be able to poll the Update Center for new versions of SC agent and or plugins.

5. Non-functional 5.1 Failure to connect to the Update Center after three retries will fail but continue to run the server and show an error message. 5.2 SC Server must use a background thread to perform tasks on a scheduled basis. 5.3 The SC server GUI shall have a new column to the Agent Monitor to identify Agents that have plugins that need to be updated.

6. Constraints

6.1 Additional code added to the SC server must maintain 70% test coverage or greater.

Snap Creator Agent Requirements

7. Functional 7.1 Every Plugin shall add a versioning method or API call to the Describe operation. 7.2 An API call shall be added to the Agent to collect installed plugins 7.3 An API call shall be added to the Agent to plugin versions

9

7.4 An API call shall be added to the Agent to agent system information.

8. Non-functional

9. Constraints 9.1 Additional non-GUI code added to the SC agent must maintain 70% test coverage or greater.

External Dependencies or Interfaces

● The Snap Creator framework is an Eclipse package and thus requires Eclipse

to build the project.

● Java Development Kit 1.6 or 1.7

● All of the Snap Creator source code is located online using Github.com in a Git repository and requires a Github account AND approval from the development team in order to clone the repository.

● Apache Ant is used for parts of the framework’s build process for the SC

Server.

● Ruby or Perl may be installed for various Snap Creator Plug-ins.

● The OS that the server VM runs on will need to be determined.

Design

High Level Design

At a high level, the Update Center is a new piece of software that is being created and hooked into the existing Snap Creator framework. Below is a diagram of the system.

10

FIGURE 1

The Snap Creator framework is shown above (figure 1) in blue and green, with blue being parts that will not be modified and green being parts that will be modified. Orange parts are new components that are being added by our team into the system. At a high level, the Snap Creator server is responsible for controlling several agents, which in turn are responsible for controlling several plugins. Each agent and server can be of different versions. The server is controlled by the user using the agent monitor GUI. Our components must hook into the Snap Creator server and allow it to manage its own versioning as well as ensure that the subsystems are all compatible.

Update Center API Based on our requirements, the Update Center API must be a RESTful web service that allows the existing Snap Creator server to connect to it. The server makes get requests to the server and receives back formatted data. Essentially, the server can fetch data about what the latest version of a plugin is, or what plugin versions are compatible with a given agent. These servers will be run locally at NetApp and will communicate with a single Update Center, meaning that one Update Center needs to support several servers. Scalability is not a problem we have to solve as the Update Center will only be handling a small number of servers.

Database The Update Center has to store versioning data in order to be able determine what to return to the Snap Creator server when it queries. It must do this using a database. The database must be populate from somewhere, so the Update Center also requires a web interface that enables a user to manually add, update, and delete versioning information.

11

Users This table keeps track of the users in the system. It uses names and emails to help identify users and has encrypted password and remember tokens to support password-secure sessions.

ID Int

Name String

Email String

Password string (encrypted)

Remember token string (encrypted)

Timestamp Datetime

Plugins/Agents/Servers Plugins/Agents/Servers need to be conscious of their name and enough information to know which version they are. They also need to know what operating system they are to disambiguate between the same version for different OSes.

ID Int

Name String

Major Int

Minor Int

Revision Int

Build Int

OS String

Timestamp Datetime

Agent-Server Compatibility

The compatibility matrices will simply show which agents are compatibility with which servers, given as IDs into their respective tables. These tables are implemented as a white list to show what is compatible with what. Similar tables are constructed for Plugin-Agent and Plugin-Server.

Agent ID Int

Server ID Int

The database has three main tables - plugins, agents, and servers - as well as cross-compatibility tables and a user table to track login information. Each plugin, agent, and server will have an id, a name, a version broken up into integer values,

12

and a timestamp. Plugins do not need a unique identifier as they can be identified by their name and version number. Cross compatibility tables will use id numbers into other tables to determine what items are compatible with what. This means that compatibility can be determined simply by looking into a table for an item with id values equal to the id of the individual components. The users table has login credentials as well as an encrypted password and session id. This is a simple system that allows for a user to login to the system and remain logged in until they log out, thus creating additional security measures to control who has access within NetApp. It has also been stated that at some point the Update Center might be accessible by plugin creators themselves, so authentication would be a must.

Admin GUI There will be a small number of users that are required to interface with the Update Center in NetApp, but it is important that they have a simple way to manage its versioning data. For this reason, the Update Center web server has a simple interface that allows a logged in user to view versioning data, create new data, and modify or delete existing data through a user interface. Creating, modifying, or deleting an entry brings up a dialog that allows the user to set the name and versioning values, which are then checked to ensure the name and version numbers are valid. This system is simple and straightforward and allows users to easily modify the internal database that effectively controls the versioning for all Snap Creator servers.

Snap Creator Server Each Snap Creator server, for the purposes of the Update Center’s development, is responsible for managing versioning for itself and all its subsystems (i.e., each agent and plugin). It communicates with the Update Center directly by utilizing web requests due to the fact that the Update Center and Snap Creator servers are located on the same network. An existing GUI helps manage individual agents, to which user interface elements will allow users to check and update to latest compatible versions.

Low Level

At a low level, most of the design to be done was on the Update Center, as the Snap Creator has already been designed and implemented by the NetApp Snap Creator team. Ruby on Rails dictates using a model-view-controller pattern which shaped a significant amount of our design process. The Update Center also is required to control versioning for servers, agents, and plugins, meaning that each of these need to be defined in code in a parallel manner.

Model The model portion of the Update Center is the database. Entries are created, read, updated, and deleted by the controller. The database is only ever modified by the controller and not directly by the user. It manifests itself as an SQL database that is

13

created and modified in Ruby on Rails code. It is also vital that data is validated as it enters the model to ensure that elements are correctly formatted.

View Users have to be able to control the information that is available in the database, but they cannot do so directly due to the manner that model-view-controller works. The view consists of the user interface that is shown to the user through the web and allows the user to manipulate the database through it. The view is outlined below in UI design and manifests as formatted web pages utilizing Twitter Bootstrap in order to be readable and straightforward. The Snap Creator server will never utilize the view when getting version and compatibility data from the Update Center.

Controller The controller is the glue between the model and view and represents the way in which elements of the view affect the model and vice versa. When the Snap Creator server makes a web request, it will go directly through the controller, check the model for information it needs to determine the return values, and then return JSON back as text.

User Interface Design

The user interface is primarily focused on being simple and straightforward for technical users. The Update Center will only be utilized directly by the NetApp Snap Creator team and approximately only every six months when they do a major release. As a result, we wanted the user interface to be easy for them to use but did not want to put in a large amount of work into creating a perfect, layman-friendly interface. Our interface is intended to model a database that we hope will be easy for the technical users to understand. We also wanted to ensure that the color scheme of the site matched NetApp for the sake of consistency. Below are some mockups that were created by Santosh.

14

FIGURE 2 The above mockup (figure 2) shows a sample list of items as they would be displayed on the web server.

15

FIGURE 3 Here is a similar page (figure 3) using the actual implemented user interface. Plugins are displayed in a tabular format with options to create a new plugin as well as show or edit an existing plugin.

Implementation

More info to be added.

Test Plan & Results

See the separate document named Testing Guide.docx for many more details including steps to setup the local environment for testing. We are using Rspec for Ruby to conduct unit testing. We currently have 39 unit tests covering the user and plugin classes using Rsepc. All unit tests are currently passing.

Rpec output

The output from Rspec will list the time taken to run the test, the number of "examples" or test run, and the number of failures. When all test are passing you will see a similar output as below, each dot on the top line is a test that was ran. Below we took 0.27518 seconds to run the test and ran 39 tests and had 0 failures.

16

....................................... Finished in 0.27518 seconds 39 examples, 0 failures Randomized with seed 37381

If a test case fails its dot will become a 'F' to reflect the failure (see example below) and also Rspec will also give additional information to help you locate the failure.

For each failing test Rspec will list

1. the test name, 2. the assert that failed 3. the expected outcome 4. location of the file containing the failing test

An example output with a failing test is below

.........F............................. Failures: 1) User when password confirmation != password Failure/Error: it { should_not be_valid } expected #<User id: nil, name: "Example User", email: "[email protected]", created_at: nil> not to be valid # ./spec/models/user_spec.rb:88:in ̀ block (3 levels) in <top (required)>' Finished in 0.23503 seconds 39 examples, 1 failure Failed examples: rspec ./spec/models/user_spec.rb:88 # User when password confirmation != password Randomized with seed 13879

In the above output

● the test name is shown in the line 1) User when password confirmation != password

● the assert that failed in the line Failure/Error: it { should_not be_valid }

● the expected outcome in the line

17

expected #<User id: nil, name: "Example User", email: "[email protected]", created_at: nil> not to be valid

● the location of the file containing the failing test, the line number of the failing test and the failing test name with the output

rspec ./spec/models/user_spec.rb:88 # User when password confirmation != password

Note if you are getting failing test that really should be passing, try restarting the server.

At this time the standard testing suite for Ruby does NOT have a code coverage tool. Through some digging we have found one called Rconv. However at this time we have not been able to get this tool working. The final report should include full code coverage reports from Rconv

Selenium

For integration and acceptance testing we are using Selenium IDE. Selenium can be used in many ways. We are using the Selenium IDE through the Selenium Firefox

plugin. This testing suite is currently using Firefox version 24 with the Selenium Plugin.

The selenium folder contains a subfolder for each suite of tests, for example the signin_page_test subfolder contains the test suite for the signin page. The test suites

and individual test are stored as .html file and the full test suite for each folder will have a filename ending in test_suite.

For example the test suite for the user sign in page is named signin_page_test_suite.html and its relative path is

\selenium\signin_page_test\signin_page_test_suite.html

To open a test suite, in the Selenium window you want to click File -> Open Test Suite... Then browse to the Update Center root folder, then into the selenium folder where all

Selenium test are contained. To open the signin page test suite navigate to the folder \selenium\signin_page_test\ Then open the file named signin_page_test_suite.html Selenium now has the test suite loaded and it is ready to run. The example below has

the signin_page_test_suite.html loaded

18

The individual test cases for the test suite are listed in the left column. The actual test code is located in the right hand pane in the shot above. To run the entire test suite click the green arrow button with the three green rectangles

To run just the single test highlighted in the left pane click the green arrow with only one green rectangle.

After running the entire test suite you will see an output screen similar the one below.

19

Note: annotated for detail

20

Black Box Test Plan - Selenium

Test Suite for Sign Up page

Correct Content Test for Sign Up Page

content_correct

Open /signup

assertTitle Update Center

assertText css=h1 Sign up

verifyElementPresent id=user_name

verifyText css=label Name

verifyElementPresent id=user_email

verifyText //form[@id='new_user']/label[2]

Email

verifyElementPresent id=user_password


Password

verifyElementPresent id=user_password_confirmation

21


Confirmation

verifyElementPresent name=commit

verifyValue name=commit Create my account

verifyElementNotPresent link=Home

verifyElementPresent link=Sign in

verifyText link=Sign in Sign in

Check Signin Link is Valid on Sign Up Page

signin_link_valid

Open /signup



verifyElementNotPresent link=Home

22



clickAndWait link=Sign in


verifyText css=h1 Sign in

Check Username field is validating correctly on sign up page

username_checks

Open /signup

Type id=user_name

Type id=user_email [email protected]

Type id=user_password

Password

Type id=user_password_confirmation

Password

mailto:[email protected]

23

clickAndWait name=commit

verifyElementPresent css=div.alert.alert-error

assertText css=div.alert.alert-error

The form contains 2 errors.

verifyElementPresent id=error_explanation

verifyText css=#error_explanation > ul > li

exact:* Name can't be blank

verifyText //div[@id='error_explanation']/ul/li[2]

exact:* Name is too short (minimum is 4 characters)

Open /signup

Type id=user_name this_name_is_really_really_really_too_long



Password


24


Password



verifyText css=div.alert.alert-error

The form contains 1 error.

verifyElementPresent css=#error_explanation > ul > li


exact:* Name is too long (maximum is 40 characters)

Check Email Field is validating correctly on sign up page

email_checks

Open /signup

Type id=user_name Blank Email User

25

Type id=user_email


Password

Type id=user_password_confirm

ation

Password





verifyElementPresent css=#error_explanation > ul

> li


exact:* Email can't be blank


exact:* Email is invalid

Open /signup

26

Type id=user_name Invalid Eamil Format User

Type id=user_email test@test


Password


Password





verifyElementPresent css=#error_explanation > ul

> li

verifyText css=#error_explanation > ul

> li


Open /signup

27

Type id=user_name Invalid Eamil Format User

Type id=user_email [email protected] not work


Password


ation

Password








Open /signup

28

Type id=user_name Email Too Long

Type id=user_email this_email_address_is_longer_than_40_ch

[email protected]


Password


ation

Password







exact:* Email is too long (maximum is 40 characters)




29

verify Password field is validating correctly on sign page

password_checks

Open /signup

Type id=user_name Password is Blank


Type id=user_passwor

d



verifyElementPresent css=div.alert.alert

-error




verifyText css=#error_expla exact:* Password



30

nation > ul > li can't be blank


exact:* Password is too short (minimum is 6

characters)

Open /signup

Type id=user_name Password is Too Short



12345


12345








31


exact:* Password is too short (minimum is 6

characters)

Open /signup

Type id=user_name Password_Confirm Error



123456


123455








32


exact:* Password confirmation doesn't match

Password

Test for a Valid Sign Up on sign up page

valid_signup

Open /signup


verifyElementPresent css=h1

verifyText css=h1 Sign up

Type id=user_name New User


Type id=user_password Password


Password



33


verifyElementPresent css=div.alert.alert-success

verifyText css=div.alert.alert-success

Signed in!

verifyText css=h1 New User [email protected]

Check home link is valid on signup page

home_link_valid

Open /signup



verifyElementPresent link=Home

verifyText link=Home Home

verifyElementNotPresent link=Sign in



34

clickAndWait link=Home


verifyText css=h1 Test Page

Test Suite for User Sign In Page

Check for correct content on signin page

content_correct

open /signin

assertTitle Update

Center




verifyElementPresent id=session_email

35

verifyText css=label Email

verifyElementPresent id=session_password

verifyText //label[2] Password

verifyElementPresent name=commit

verifyValue name=commit

Sign in

verifyText css=p exact:New user? Sign up now!

verifyElementPresent link=Sign up now!

verifyText link=Sign up now!

Sign up now!

Check that the Signin link is valid on the sign in page

signin_link_valid

open /signup

36





clickAndWait link=Sign in



Check that Signup link is valid on sign in page

new_user_signup_link_valid

open /signin


37


verifyText css=p exact:New user? Sign up now!


verifyText link=Sign up now!

Sign up now!

clickAndWait link=Sign up now!


verifyText css=h1 Sign up

Test for Unregistered User Sign In Page

user_not_registered

open /signin

38

type id=session_email [email protected]

type id=session_password

Password




Incorrect credentials

Test Valid user sign in on Sign in page

valid_user_signin

open /signin






39

verifyText link=Sign up now! Sign up now!

clickAndWait link=Sign up now!

type id=user_name Valid User

type id=user_email [email protected]

type id=user_password Password

type id=user_password_confirmation

Password


verifyElementPresent css=div.alert.alert-success

verifyText css=div.alert.alert-success

Signed in!

Additional Black Box Acceptance test and additional Unit test will be added here as they are completed.

Please see the separate document titled Testing Guide for more details and setup information.



40

Suggestions for Future Teams

One of the largest issues our team had to deal with are sync and commit issues in GitHub. We decided to use the GUI manager to do commits and pulls from the server because it seemed easy to use. There have been multiple issues with us using the “sync” action to push our commit that would make the branch unstable. In the future I would suggest that there should be a couple meetings within the team to learn about GitHub and how to use it to prevent any large issues to the branch.

Iteration planning was also another problem we had near the beginning of the project. It is beneficial to the team if there are well defined requirements and stories for each iteration before the iteration starts. This will allow you to work more on your tasks than trying to figure out what you need to be doing.

Ruby on Rails was a new framework and language for us to learn and develop. Because of this most of our first iteration went to researching and learning. If you are not familiar with this framework do plan for a couple of weeks of learning before developing.

41

Task Plan

Team 14 Task Plan

Item Owner(s) Due Date Status

Iteration 1 ALL 9-24-2013 Complete

● OPR 1 ALL 9-13-2013 Complete

● Setup and research ALL 9-24-2013 Complete

● Setup Development Environment

ALL 9-24-2013 Complete

● First draft of Interim Progress Report (IPR)


● Set up basic Ruby on Rails web server

Zack 9-24-2013 Complete

● Create database structure for plugins

Dylan 9-24-2013 Complete

● Create mockups for UI interface for Update Center

Santosh 9-24-2013 Complete

● Ensure that plugins in the database can be managed via a controller


● Add sample testing data into the model

Dylan 9-24-2013 Complete

● Add a web request to find latest version for a plugin


● Do Tech exploration and Design testing framework for our project

Jason 9-24-2013 Complete

Iteration 2 ALL 10-08-2013 Complete

● Create Acceptance Test for Sign up webpages


● Create migrations for server Dylan 10-08-2013 Complete

42

and agent tables

● Create Acceptance Test for Sign up webpages


● Create Installation Guide Jason 10-08-2013 Complete

● Admin can create, update, or delete items from the UI


● OPR 2 Zack 10-07-2013 Complete

● Plugin data validation before saving


● Start API Documentation Dylan 10-08-2013 Complete

● Finalize database schema Zack 10-08-2013 Complete

● Add unit test for User class Jason 10-08-2013 Complete

● Form for put/posting data Santosh 10-08-2013 Complete

Iteration 3 ALL 10-22-2013 In progress

● Investigate SC Framework Code Base for Version API addition

Jason 10-22-2013 In progress

● Resolve remaining SC-Framework build issues


● Update Draft Interim Project Report to Final Interim Project Report


● Create Acceptance test for Plugins page

Jason 10-22-2013 Not started

● Convert Acceptance test for Sign In page to Selenium


● Convert Acceptance test for Sign Up page to Selenium


● Web requests for determining what Plugins/Agents/Servers are compatible with a given component


43

● Convert Installation and Testing Documents to Github Markdown Language

Jason 10-22-2013 Not started

● Update Document with Chuck's suggestions

Zack 10-22-2013 In progress

● Seed database with more data

Dylan 10-22-2013 In progress

● Create remaining database table migrations

Dylan 10-22-2013 In progress

● Work on IPR ALL 10-21-2013 In progress

Posters & Pies ALL 12-6-2013 Not started

Installation Documentation Jason 12-13-2013 In progress

Final Presentation ALL 12-13-2013 Not started

Developer's Guide See separate document titled Developer Guide

User's Guide See separate document titled User Guide

Installation Guide See separate document titled Install Guide