members: lee farrell andrew graziano terry hernandez...

Group #:

4

Members: Lee Farrell

Andrew Graziano Terry Hernandez

Jared Scallan

ISDS 4125 Fall 2014

Table of Contents

Table of Contents ............................................................................................................................................................................... 2

Executive Summary .......................................................................................................................................................................... 3

Work Plan ............................................................................................................................................................................................. 4

Feasibility Study ................................................................................................................................................................................ 5

ERD Diagram ....................................................................................................................................................................................... 6

DFD Diagram ....................................................................................................................................................................................... 7

Physical Process Model ................................................................................................................................................................... 8

Functional and Non-Functional Requirements ..................................................................................................................... 9

Improvements................................................................................................................................................................................ 9

Functional ........................................................................................................................................................................................ 9

Non-Functional .............................................................................................................................................................................. 9

As-Is System.................................................................................................................................................................................. 10

Use Cases ............................................................................................................................................................................................ 11

Architecture Design ........................................................................................................................................................................ 14

CRUD .................................................................................................................................................................................................... 15

Alternative Matrix ........................................................................................................................................................................... 16

Hardware and Software Specifications: ................................................................................................................................. 17

Structure Chart ................................................................................................................................................................................. 18

Program Design Specifications .................................................................................................................................................. 19

Application Screenshots ............................................................................................................................................................... 22

Data Storage Design ....................................................................................................................................................................... 23

System Conversion Strategy ....................................................................................................................................................... 24

Project Assessment: ....................................................................................................................................................................... 25

Test Plan ............................................................................................................................................................................................. 26

Jarvis User Manual .......................................................................................................................................................................... 27

Executive Summary

We will be designing a system for the purpose of improving operations at the camera checkout

center. We will design a system that is user friendly and can be used with future information and

hardware upgrades. The system will have a single database and it will communicate directly with a

webserver to host the application forms. Through these forms the manager and student workers will be

able to edit records and process checkouts/returns. The system will also create a monthly report for the

purpose of tracking inventory and send it to the manager. The goal of this system is to ensure ease of use

and upgradeability.

The target audience of this system will be Students who are in need of video equipment, the

student workers who will process checkouts and inventory, and the manager who will oversee

operations and have access to all systems.

Work Plan Goal Time

Estimates

Actual Time Due Date Status Task

Dependencies

1 Phase 1/2 1 week 2 days 10/7 Turned in

2 Phase 3 1-2 weeks 1 week 11/2 Awaiting

Feedback

Phase 1/2

3 Phase 4 2-3 Weeks 12/1 Open Phase 1/2/3

*assumed all members contributed equally

Feasibility Study

Technical feasibility: About 2 to 3 months given to make new program. Knowledge of Visual Basic and Microsoft Access a must. Must make it able to run through a web browser to run on the iMac Decently Large project but given the entire semester should be possible

Economic Feasibility Well basically not applicable since using students. Huge benefits as a new program which will return faster and more efficient work. The gains are time savings. Costs are free except time that must be used to meet with students.

Organizational Feasibility The users (student workers) of the program should find it very simple to use. It will fit into the area to replace the current system with a very small learning curve. Management/Champion will support this into his room of business. The system should improve the overall flow of check-out/check-in of equipment.

ERD Diagram

DFD Diagram

Physical Process Model

Functional and Non-Functional Requirements

Improvements

1. Seamless data between inventory management and invoice management.

2. Add database redundancy for the purpose of backup.

3. Create a simpler, easy to use GUI that performs better than current system.

4. Make the system accessible from any browser.

5. Create a simple but robust inventory management system.

Functional 1. Inventory Management

1.1 The system will allow the manager to quickly determine which inventory items are checked out,

and by whom.

1.2 The system will populate all data fields on check out and check in based on the customers PAWS ID.

1.3 The system will generate metrics detailing inventory status displayed in a dashboard. 1.4 The inventory tracking system will use both a “quick”, and “detailed” inventory view in the GUI,

with collapsible kits and corresponding item checklists. 2. Invoice Management

2.1 To initiate checkout the customer will specify a premade kit, item, or set of items. 2.2 The checkout process will generate an invoice number referencing the items and/or kits

checked out and the customers PAWS ID, by which inventory management metrics will be generated. 2.3 At check in, upon entering the customers PAWS ID the corresponding invoice will be returned.

The student worker will then be prompted to verify the items that should be returned via virtual checklist. These fields will translate directly to inventory sheets. If an item is missing the system will prompt the student worker before continuing.

2.4 Custom kit combinations will retain their kit-item field designation which will allow us to save the custom kit for future use. (Specifically for the GoPro, but will accommodate future items).

Non-Functional 1. Operational

1.1 The database should be stored on a primary machine with a single redundant backup. 1.2 The interface should be web based and accessible through any browser. 1.3 The student worker should use an iPad for check in and check out. 1.4 The virtual checklist at check in should show pictures of the items to be returned.

2. Reliability: 2.1 System must function smoothly and consistently.

3. Upgradability: 3.1System must be able to incorporate new devices and system upgrades smoothly.

4. Security: 4.1 System must adhere to basic security standards in code, application GUI, and check in/out. 4.2 System should have login restricted access.

5. Manageability:

5.1 System must provide manager-friendly features such as generating useful reports and at-a-glance metrics. 6. Interoperability:

6.1 Systems must seamlessly interlink across all interfaces from inventory and reports to check in/out data. 7. Data Integrity

7.1 Data must adhere to standard guidelines in terms of structure. 8. Usability

8.1 System must be user-friendly for users, employees, and managers. 9. Recoverability:

9.1 Data must be recoverable in the event of damage or loss. 10. Serviceability:

10.1 System must be serviceable by in-house team.

As-Is System Person:

First Name

Last Name

LSUID #

myLSU ID

LSU Email

Phone Number

Inventory Item:

Name

Type (Canon Vixia HV40, GoPro Hero3+ Black Edition, GoPro Dual Hero System, SanDisk Extreme Class 10

45 Mb/s SD Card)

Serial Number

Condition

Status (Available, Not Available, Lost, Damaged, etc.)

Needs Permission (Boolean)

Permission Requirement Statement

Last Price Paid

Replacement Cost (Last Price Paid + 25%)

Checkout:

Item

Person

Checkout Date

Return Date

Due Date

Extensions

Use Cases

USE CASE NAME: Check Out Inventory

PRIMARY BUSINESS ACTOR:

Student Worker

OTHER PARTICIPATING ACTORS:

User

DESCRIPTION: The user specifies if he wants a premade kit, or item, or group of unique items. Student worker meets those needs by creating an invoice.

PRE-CONDITION: Item is Available

User has an account

TRIGGER: User requests inventory options Typical Course of Event:

User requests inventory

Student worker verifies that inventory is in stock.

Student worker creates ne invoice.

Use receives item.

Alternate Course: NONE

USE CASE NAME: Check In


User


Student Worker

DESCRIPTION: User returns inventory. Student worker checks returned inventory against the invoice. Student worker restocks inventory.

PRE-CONDITION: Verify Existing invoice

TRIGGER: User returns checked out items. Typical Course of Event:

User returns inventory

Student worker accesses invoice

Student worker verifies all inventory has been received

Student worked updates inventory

Alternate Course: User does not return inventory o Student worker updates inventory

User does not return all items o Student worker identifies absent items o Student worker updates inventory

USE CASE NAME: New User


Student Worker


None

DESCRIPTION: Student worker adds new users information to the description PRE-CONDITION: User is LSU student

TRIGGER: New user wishes to check out inventory Typical Course of Event:

Student worker enters all necessary user information

Student Worker updates data


USE CASE NAME: Create Kit


Manager


None

DESCRIPTION: Manager Selects items from inventory and creates the aggregate kit PRE-CONDITION: Items exist in inventory

TRIGGER: Manager experiences high demand in the same combination of items Typical Course of Event:

Manager chooses items by ID# Manager creates database entry in kit table Updates Data


USE CASE NAME: Add Inventory


Manager


NONE

DESCRIPTION: New inventory has been received and must be added into the database.

PRE-CONDITION: Items are in working order

TRIGGER: Manager Receives new inventory Typical Course of Event:

Manager enters all necessary information

Manager updates inventory


USE CASE NAME: Audit Inventory


Manager


NONE

DESCRIPTION: Once a month, manager checks inventory against inventory reports PRE-CONDITION: NONE

TRIGGER: Automatic monthly generated report Typical Course of Event:

Manager receives monthly report

Manager verifies invoice report matches inventory


Architecture Design

iMac/Database

Server

CRUD

Checkout Check In Add User Add Inventory Create Kit Audit Inventory

Person Entity

LSUID R R C R R CRUD

CheckID R R R R R CRUD

Fname R R C R R CRUD

LSUEmail R R C R R CRUD

Lname R R C R R CRUD

LSUIDNum R R C R R CRUD

MyLSUID R R C R R CRUD

PhoneNum R R C R R CRUD

Checkout Entity

CheckID C R R R R CRUD

KitID R R R R R CRUD

LSUID R R R R R CRUD

cktDate C R R R R CRUD

dueDate C R R R R CRUD

SN R R R C R CRUD

LineItem Entity


SN R R R R R CRUD

Item Entity

SN R R R C R CRUD

Name R R R C R CRUD

Type R R R C R CRUD

Condition R U R C R CRUD

Status U U R C R CRUD

PRS R R R C R CRUD

lastPricepaid R R R C R CRUD

replacementCost R R R C R CRUD

Kit Item Entity

SN R R R R C CRUD


Kit Entity



Alternative Matrix

Evaluation Criteria Relative Im

portanceAlt 1 (M

icrosoft Access)Score

Weighted Score

Alt 2 (Sharepoint)Score

Weighted Score

Design Issues:

Create Forms

20Code in VB.net/ASP.net

5100

ASP.net3

60

Choose Data Field Values20

Standard Data types5

100Standard Data Types

5100

Choose Hosting Service20

Web-Page coding compatible

480

Web-Page Coding Compatible

5100

Technical Issues:

Populate Data Fields (Add Inventory.

User, and Invoice Data)5

Standard Audit4

20Sharepoint Audit

210

Train Staff to use new system25

375

Economic Issues:

Cost10

University License (Free)5

50University License (Free)

550

Total:100

26425

20320

Hardware and Software Specifications:

Hardware: o A PC/Mac 1T of Storage

o 8G RAM o Intel i5 processor o Keyboard o Mouse o Monitor

Software:

o Web browser (Google Chrome/Safari/IE) o Microsoft Access 2013 or newer

Structure Chart

Program Design Specifications

NAME: 1)Home Page

PURPOSE: Navigate to other pages from home screen

CODE: HTML

EVENTS:

1.1 User clicks Checkout button 1.2 User clicks Add Asset button 1.3 User clicks Add Student button 1.4 User clicks check in button

INPUT NAME: TYPE: PROVIDED BY: NOTES:

TYPE: PROVIDED BY: NOTES:

PSEUDOCODE:

Take user to corresponding page on button click.

NAME:2)New Asset

PURPOSE: Adds new inventory to the DB

CODE: HTML/SQL

EVENTS: 2.1 Fields are entered and Add Asset button is clicked


2.1.1 SKU 2.1.2 Asset Name 2.1.3 Asset type 2.1.4 Quantity 2.1.5 Replacement Cost 2.1.6 Asset type

2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6

OUTPUT NAME: TYPE: PROVIDED BY: NOTES:

PSEUDOCODE:

Insert data from text fields into the database

NAME: 3)Add New Student

PURPOSE: Adds a new user to the DB for the purpose of access to checkout system

CODE: HTML/SQL

EVENTS: 3.1 User enters data fields, user clicks Add Student button


3.1.1 First Name 3.1.2 Last Name 3.1.3 LSU ID 3.1.4 Email 3.1.5 Phone Number 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5

OUTPUT NAME: TYPE: PROVIDED BY: NOTES:

PSEUDOCODE:

Insert data from text fields into database

NAME: 4)Check In PURPOSE: Checks items back into inventory

CODE: HTML/SQL

INPUT NAME:

4.1.1 Last Name 4.1.2 Transaction ID

PSEUDOCODE:

Search transactions by student name,

select corresponding transaction ID

NAME: 5)Check Out

PURPOSE: Checks items out of inventory

CODE: HTML/SQL

INPUT NAME:

5.1.1 Student Name 5.1.2 Item/Kit ID

OUTPUT NAME:

5.1.3 Transaction ID

PSEUDOCODE:

Create transaction from information in input

Fields. Generate transaction ID

Application Screenshots

Home Screen

Check Out

Check In

Add Student

Add Asset

Data Storage Design

System Conversion Strategy

The application we designed is made to be used with SharePoint. The admin over the site will need to go into access and log in with their credentials

to get it set up on the server. Depending upon the exact data types in the current system a few fields might need

to change to different name. This is mainly referring to the state names for all the items etc. Training isn’t completely necessary assuming the student worker has had at least

some use with Microsoft Access. If anything a short little overview should get them going with ease.

Project Assessment:

Team Review:

o Our team worked very well together. We had no issues with communication.

We had been in groups before for previous ISDS projects and worked well.

Everyone was punctual and available. We had a good mix of skill sets. We

delineated work fairly and to our strengths.

o Our strengths: We are all pretty close friends so it made communication

pretty easy. We had a good mix of skills as stated before. We had strong

coders and designers that made the process fairly efficient.

o We all have time consuming internships during this semester, so I would say

our time management is where we could have improved.

System Review:

o The project itself was pretty hefty. It definitely took a lot of time and

communication. We learned a lot about web forms and refreshed our

knowledge on access that could be used for future projects.

o Looking back, I’d say we could have taken a different approach as far as our

model. I think we overcomplicated some things and tried to do too much.

o Future suggestions for the project: We think that it would have been more

beneficial to have more class time. The project was pretty robust for what

we’ve learned in previous classes. It also didn’t help that when we asked the

client for answers they were very general. More hands on class group work

would have helped immensely with our busy schedules. Also, a lot of the

requirements in the phase documents don’t accurately pin point what or how

to properly do things. We think a standardized project rather than a client

would have been more easily graspable because of the generality the client

provided and difficulty in figuring out how exactly to do certain tasks.

Test Plan Program Id: Jarvis Version #: 1 Tester: Jared Scallin Date Designed: 11/2/14 Date Conducted: 11/30/14 Results: Passed Test ID: 1 Requirement Addressed: Add Asset Objective: Ensure information entered is input into tables. Test Cases

Interface ID Data Field Value Earned 1. ItemName GoPro 2. ItemName FlipCam1 3. ItemName Didn’t work 4. ItemName Tripod 5. ItemName extra Lithium Battery 6. ItemName GoPro4

Expected Results/Notes: All should input name into fields. Actual Result/Notes: Only 3 gave back a blank response and all others work. Inspection to figure out problem will be done.

Jarvis User Manual

1. Open the Switchboard form located on the left side in the Lending Library.

2. Add inventory to the database by selecting Add Asset in the Switchboard.

Input the data in the designated fields then hit Add Record. The data will be stored in the Asset table.

3. Add User:

a. Select the switchboard tab located at the top of the form. That will return

you to the switchboard where you can select Add user.

4. Check In:

a. Follow the steps above to get to the Check In form. Input your data and hit

Save and Close.

5. Check Out:

a. Follow the steps above to get to the Check Out form. Input your data and hit

Check Out.

6. Build Kit:

a. Follow the steps above to get to the Build Kit form. Input your data and hit

Add to Kit.

members: lee farrell andrew graziano terry hernandez...

Documents