Systems Analysis & Design Project

Share-A-Bull Bikes
Systems Analysis & Design
Group: Team Earthworm
Amanda Blakley, Joseph Carusillo, Christian Hernandez,
Kaleb Paker

1 | Page
Table of Contents
Executive Summary: 2
MILESTONE 1: 3
PROBLEM SUMMARY/PROPOSED SYSTEM REQUIREMENTS: 3
Technical Feasibility: 3
Economic Feasibility: 5
Organizational Feasibility: 8
Estimating 9
Project Plan: 10
Interviews: 11
MILESTONE 2: 12
Use Cases: 12
List of Use Cases: 12
Time Alert System – Christian Hernandez 13
Peak Route System – Kaleb Parker 14
User Feedback System - Joseph Carusillo 15
Tracking Maintenance Issues System - Amanda Blakley 16
Process Model: 17
Entity Relationship Diagram: 23
Data Dictionary and Metadata: 24-25
MILESTONE 3: 26
Input Screens 26-28
Output Screens 29-31
Printed Report 32
Test Summary 33
Test Plan 33-35
Conversion Strategy 36-37
Milestone 3 end/grading 38
Milestone 3 Meeting Minutes 39

2 | Page
Executive Summary:
As the University of South Florida analysts and technology specialists adjust to the planning phase of the “Share-
A-Bull Bikes” system, for the Office of Recreation, a few redundancies within the system as-is have already been
identified. Furthermore, the assembled team is making great headway and ready to implement a vision to create a more
efficient bicycle sharing project. At present, the additional systems have been mapped with four distinct use cases and
corresponding Level 1 Data Flow Diagrams. These Use Cases and data modeling methods provide an important outline to
send out user alerts to prevent riders from facing fines, spot trends in maintenance expenses, obtain user feedback and
map popular on-campus routes in-order to increase availability of bicycle inventory nearby. In addition, Entity
Relationship Diagrams (ERDs) and data dictionaries provided more information on the key attributes of the elements
within sub-systems and datastores. The information drafted and provided in subsequent documents demonstrates great
potential for improved functionality as well as tremendous cost benefits and customers satisfaction with an improved
Share-A-Bulls Bikes program. The remainder of the project is estimated to take approximately 1 more month to complete
in full.

3 | Page
MILESTONE 1:
PROBLEM SUMMARY/PROPOSED SYSTEM REQUIREMENTS:
The project's goal is to rework and improve the current Share-a-Bull Bike program at USF. We intend to gather
usage statistics from the bikes, including peak hours and routes, add the ability to send out texts to alerts users before they
are to receive a fine, track information about maintenance and loss costs of the bikes, as well as obtain user/rider
feedback. Our analysis should allow us to see what aspects of the current system needs improving and what actions need
to be taken to meet our current goals.
Nonfunctional
Requirement
Description Examples
Operational The physical/technical environment the
system will operate in.
● The system will run on android and IOS
devices.
● The improvements will continue to work with
all existing systems.
● Capable of sending alerts to users before an
event occurs.
Performance The speed, Capacity, and reliability
of the system.
● The system should be available 24 hours a day,
7 days a week.
● The system should be constantly updating with
information to provide and accurately gather
real-time information.
Security Who has access to the system and
under what conditions.
● Access to the system includes all staff and
student at USF
Functional
Requirement
Description Examples
Process-Oriented A process the system must
perform.
● Gather information on peak hours and routes
● Gather user/rider feedback.
● Send out alerts to users before they would
receive a fine.
Information-
Oriented
Information the System must
contain.
● Track information on maintenance and loss
costs of the bikes.

4 | Page
Technical Feasibility:
Familiarity with application: The intention of this project is mostly to increase the visibility of statistics for the staff of
the department of Campus Recreation, as well as provide additional functionality to the mobile application that current
users use to access bike location and make reservations. Since the front end of the application is not changing beyond the
scope of the information provided we are unlikely to see a change in the ability of the staff to read and understand what
they are being given. The change is mostly coming in the backend, thankfully all of the requests being made are already
available as information and simply need to be categorized and moved into the front end of the application. In order to
allow the input of information dealing with maintenance, an application will need to be created to allow this to be added.
We will also need to include an automated system to alert that a rental is soon to expire, this is also not likely to decrease
familiarity with the application as the nature of the application is likely to have been experienced previously.
Familiarity with technology: System technology is unlikely to be changed drastically, we are increasing functionally not
altering the technology behind the system. When we consider what our client is asking for the system to additionally
provide all of this is information that is readily available to us. The addition of an application that allows the maintenance
staff to include reports of where and when maintenance requests are submitted and completed and the nature of the repairs
will need to be included.
Project size: The project size appears much larger than it actually is, because this is not a new system it is a functionality
overhaul of a system that already exists and already works but just needs to work better. There will be no additional
systems tied into the system than what already exists, there will simply be more information stored and analyzed than was
previously done so. The largest part of this project is how many of USF systems it is tied into, however thankfully this is
unlikely to change and those ties have already largely been made and are likely to be maintained through the course of this
project.
Compatibility: As this project is performed an emphasis will be centered around compatibility, in an effort to save costs
and the desire not to change every system on campus in order to fulfil the needs of this project. Most of the core of this
system will not be changing, the largest change we will be making is to the interfaces (software not hardware) that the
users will experience. The other changes made will be built to conform with existing systems.

5 | Page
Economic Feasibility:
This section includes a summary of the economic feasibility study associated with updating the Share-a-Bull bike sharing
program.
Introduction
An in-depth analysis of the of the Share-a-Bull bike system shows that back-end software updates on the existing program
will make it more efficient in sharing bicycles on the University of South Florida Tampa campus. As exhibited in the chart
below, a cost-benefit analysis of the potential updates could lead to both tangible and intangible benefits, including the
improvement of the functionality and efficiency of the project.
The above figure suggests that the benefits tied with upgrading the back-end application system includes increased
revenue collected from user fees and fines, additional community sponsorships and donations, the inclusion of a higher
“Green Fee” for students and a potential decrease in existing bus, shuttle and other traditional transportation staff at the
Transportation & Parking Services department on-campus.
In contrast, the evaluation exhibits a number of costs. One-time, start-up costs would include the need for expanded office
space and hardware. This is vital for newly hired analysts and interns to develop the requisite software, as well as

6 | Page
maintain social media outreach as well as an initial advertising campaign. Also, the recurring operational costs are as
follows: vendor expenses, software and hardware maintenance and new hires including a bicycle technician and four
Systems Analysts. The analysts will collect important data that would ultimately assist in an improved redistribution of
bicycles based on demand and avoidance of proven high-risk areas where bike theft or damage occurs frequently.
Economic Analysis
The Return on Investment (ROI) was determined by subtracting the total costs from the total benefits and then dividing
the figure by total costs. This equation resulted in an estimated 255% ROI, which leads our team to conclude that the
project is worthwhile. The Net Present Value (NPV) also demonstrates that the Share-a-Bull program updates are
economically viable. The overall NPV is $1,815,381, which would provide a hefty revenue for the University of South
Florida and the Tampa Bay community.
Break-Even Point
As seen in the table, our team initially estimated a break-even point in Year 2. After performing the initial calculations,
the BEP fraction was totaled at .25 which means the actual break-even will occur after only 1.25 years.
The Break-Even Analysis chart re-enforces the low-risk of investing in the project. As seen in the chart, the benefits
would rise steadily in contrast to the total costs associated with running the new program.
Additional Benefits
In prior sections, discussion has focused on tangible benefits. However, there are several intangible benefits that would result from the
implementation of the updated program. The following chart juxtaposes such benefits.

7 | Page
Tangible Intangible
● Increased Revenue from User Fees ● Less Parking Lot & Road Congestion
● Additional Sponsorships & Donations ● Decreased carbon emissions
● A Fixed Annual “Green” Fee ● Health Benefits for Users
● Decrease in Existing Transportation Staff ● Decreased car & bus dependency
Conclusion
According to the economic feasibility study performed on behalf of the University of South Florida demonstrates that including the
back-end improvements would be a sound investment. The ROI, NPV and BEP numbers prove the viability of the project. Lastly,
intangible benefits such as decreasing USF’s carbon footprint, road congestion and a lowered dependency on traditional transportation
provide an even stronger case for moving ahead with the software development within the Share-a-Bull bike project.

8 | Page
Organizational Feasibility:
Strategic Alignment:
The goals of the project are to gather data on peak hours/routs to find out if there needs to be an influx of new bikes into
the current system, and how to redistribute them. The top executive and campus recreation would also like to see if they
should improve their notification system. Lastly, they would also like information on the maintenance needed and any
other issues the users have with the current system.
Business Structure:
The business structure for Share-a-Bull Bikes is very simple/convenient for the users. there is a mobile app and website
that you can make an account on which is free for 6 months. That will give you a 4-digit code to be used for faster access
to the bikes and make reservations from anywhere on the app. If there are any damages or improper use locking the bikes
the owner of the account will be fined. There is a set area that the bikes are allowed to be used in, any violations to this
rule will also result in a fine.
With this structure there is a top executive and a campus recreation leading the business. They run the company but don’t
have a high liability in the company. The risk falls to the members that use the Share-a-Bull Bikes. They have full
responsibility for any damages or injuries that might occur using the bikes.
Stakeholder Analysis:
The goals of the project and business are very compatible, and due to that there is a low risk for the organization. The top
executives and campus recreation are the Champions and organizational management for the project. The System users
are the volunteers and survey members that have an input into the development and success of the project. The Champion
is the top executive and the organization management is the campus recreation. The project has a high impact on Campus
recreation, but a low impact on the top executive. The project has a high impact on the System users. The top executive
and system users has a high influence over the project. The organization management has a low influence.

11 | Page
Interviews:
Goal:
The goal for the interviews are to obtain valuable information from the public community here on USF Tampa-campus
about how to improve and make Share-a-Bull Bikes more efficient for the students and staff members.
Interview Questions:
1. What are the tasks associated with your position on the Share-A-Bull program?
Assumed Answer: “I analyze all collected data to continue providing excellent service”
2. Would an alert system that provides alerts at 5 and 10 minutes prior the end of the free ride better your experience?
Assumed Answer: “Yes, It would allow customers to avoid possible charges.”
3. Would a new bike tracking system locate peak traffic and assist the rider in choosing the best route?
Assumed Ans: “Yes, that would help us know what areas have a higher population of people that want to use the bikes.”
4. Where do you think is the most convenient place for a new share-a-Bull Bikes hub?
Assumed Answer: “Near the MSC or Cooper Hall”
5. Is there an easier way of getting effective feedback from IT staff?
Assumed Answer: “Through the CANVAS system and mobile push notifications”
6. How much would you pay for a share-a-Bull-Bikes account?
Assumed Answer: “A reasonably higher single payment under $10.00 per 6 months or a low monthly fee”
7. Do you have any additional comments on how to improve the bike sharing program?:
Assumed Answer: “Anything improving the mobile application or the condition of the bikes themselves.”

12 | Page
MILESTONE 2:
Use Cases:
List of Use Cases:
1. Time Alerts – Christian Hernandez
2. Peak Routes – Kaleb Parker
3. User Feedback – Joseph Carusillo
4. Maintenance Cost Tracking – Amanda Blakley
5. Peak Times
6. Location Alerts

13 | Page
Time Alert System – Christian Hernandez
Use Case Name: Time alert System ID: UC-1 Priority: High
Brief Description: Alerting riders that the time for their free ride is running out when they have 10 and then 5 minutes left for their ride. This will be
accomplished by push notifications/alerts through the mobile app.
Actor: Share-a-Bull Bike Application (Social Bicycles)
Trigger: When the rider has 10 and 5 minutes left for their free ride.
Type ◻ External ◻☑ Temporal
Preconditions:
1. The app must be functional and operational on the user’s mobile device.
2. Alert notification system is online and connected to the time tracking database.
3. The app must capable of connecting to the alert system to send push notifications/alerts to the users.
4. User is authenticated to the bike and the app.
Normal Course
1. User begins free ride time.
2. The time alert system calculates remaining free ride time.
3. The time alert system will begin tracking user’s free ride time.
4. Time alert system notifies rider of remaining time through the app.
5. 10 minutes remain in the user’s ride time, alert system computes 10
minutes remain in the user’s free ride time
6. The alert system sends a push notification that the free ride time is near
expiration to the app.
7. 5 minutes remain in the user’s ride time, alert system computes 5 minutes
remain in the user’s free ride time
8. The alert system sends another push notification through the app that the
free ride time is nearing expiration.
9. Free ride time is over.
Information for Steps
 User’s start time
 User’s available free ride time
→ Push Notification
 Push Notification
Alternative Course(s):
1. The user ends session before first notification.
2. The user ends session after first notification but before the second.
3. The user ends session before ride time is over.
a. User begins a new session.
b. User ends session before free ride time ends.
Postconditions:
1. The App timer resets at 12:00AM daily.
Exceptions:
1. App is unable to send push notification, system will continue as if notifications were sent.
Summary:
Inputs Source Outputs Destination
Users available free ride
time
Users ride start time
Users ride end time
Users
App
Push notifications/alerts Users
App

14 | Page
Peak Route System – Kaleb Parker
Use Case Name: Identification of Peak Routes ID: UC-2 Priority: High
Brief Description: This system will serve to identify and track the most common routes used by consumers that are using our products. This will be
accomplished by the tracking of usage of our products and correlating repetitious behavior and then preparing that data in a way that can be easily
understood.
Actor: Bike Tracking and Management System (BTMS)
Trigger: At 3 AM the system will issue a pull request for GPS data from the bikes onboard computer (OBC).
Type ◻ External ☑ Temporal
Preconditions:
1. The bikes onboard computer must be reachable (on the network, powered, and responsive).
2. The tracking system must be able to pull the data from the bikes and be properly authenticated.
3. The PR system must be online and not running analytics on previously obtained data.
4. Watson analytics must be reachable and accepting input.
Normal Course
1. At 3 AM the peak route system will download bike GPS data.
2. The Peak Route system (PR System) will import the GPS data from the bike into
its assigned database table “Bike Route Data.”
3. The PR System will acknowledge the receipt of the data from the bike for the
purposes of data retention policy of the Bikes OBC.
4. The PR System will take the GPS data and plot it to a map of the serviceable
area of the bikes (The University Campus).
5. The PR System will take the exported database table for the day, week, and
month, and upload it to Watson Analytics for analysis of trends.
6. Watson Analytics will return with the most common routes that were taken for
the previous day, week, and month.
7. Report will be generated from analysis data and map (generated in step 5) will
be attached and be saved in the PR System file storage.
 GPS data from each bike
 Compiled GPS data
→ Receipt of data
→ Map of GPS data
→ Exported data
 Analysis
→ Generated Report
1. The bikes fail to authenticate or fail to send data, data will be retained indefinitely and ignore data retention policy.
2. The bikes are not connected to network, last known location will be logged and a report generated for maintenance.
3. Network is unavailable, PR system will attempt to issue pull request every hour until network is available.
4. Watson Analytics is unavailable, PR system will attempt to upload data every hour until available
Postconditions:
1. Maps, GPS Database, and Analytic data are stored and can be pulled.
2. Bikes data retention policy regularly clear self of data that has been backed up to database.
3. Daily, Weekly, and Monthly reports are generated.
Exceptions:
1. Bike is placed in maintenance mode and thus ignore pull request for data and do not track location.
2. Network unavailability due to system outage or overuse fails to provide enough bandwidth to upload data.
3. Bike is taken off property (stolen) and is not on the network (GSM network activates and uploads GPS data to “Stolen Bike GPS” Database
Table)
Summary:
GPS Data Pull Request
Bike’s GPS Data
Peak Routes System
PR System Database
Bike’s GPS Data
Peak Route
Analysis
PR System Database
PR System File Storage
User Feedback System - Joseph Carusillo

15 | Page
Use Case Name: User Feedback ID: UC-3 Priority: HIGH
Brief Description: This use case describes how the user enters feedback into the system. This is accomplished when the user logs onto the mobile
application or website and submits a user feedback form. An incident report is created for immediate forms and a push notification/alert is sent via the
mobile application.
Actor: User
Trigger: User wants to give feedback on any anomaly that may have taken place
Type ☑ External ◻ Temporal
Preconditions:
1. User has feedback on an anomaly
2. User accesses (logs in) the mobile app or website
3. New feedback system is on-line
4. Feedback datastore is on-line
Normal Course
1. Feedback system is selected
2. Automated notifying system activated
3. Feedback system information is collected
4. Incident report is created
5. Feedback system asks about immediacy
6. User clicks Non-immediate
7. User clicks option for new Alert system
 Account login: Username/Password
→ Company personnel Obtains Account info
 Feedback info collected into systems
 Feedback info used to create a report
→ Info on condition of bike
→ System puts form in database
 User gives feedback on new Alert system
1. For immediate feedback human involvement is necessary
2. Then a new incident report form is created
3. Then a new feedback form is created
4. The data goes to the Bikes maintenance services
Postconditions:
1. Database info recorded
2. User logs-off Mobile App/website
Exceptions:
1. User forgot login info
2. Datastores are offline
Summary:
User Feedback
User Account info
Feedback System
Feedback Database
Mobile App
Website
User
Feedback info Mobile App
Website
Account Database

16 | Page
Tracking Maintenance Issues System - Amanda Blakley
Use Case Name: Tracking Maintenance Issues ID: UC-4 Priority: High
Brief Description: This use case describes how the analyst tracks and records maintenance repairs for report preparation. The report includes a summarization of expenses
for both common and anomalous repair issues.
Actor: Business Analyst
Trigger: The manager requests a report of expenses and costs associated with and maintenance repairs.
Type ☑☑ External ◻Temporal
Preconditions:
1. Business Analyst is authenticated
2. The User Identification datastore is available and on-line
3. The Maintenance Tracking datastore is available and on-line
4. The Summary Reports datastore is available and on-line
Normal Course
1. The Analyst logs into the secure User Identification datastore
2. The Analyst enters in a date range to organize all current bicycle maintenance
and repair events
3. All maintenance details are retrieved from the Maintenance Tracking datastore
4. The maintenance information is transferred into Tableau for the program to
analyze trends and prepare charts
5. The analyst organizes the statistical data and generates the final Maintenance
Summary Report
6. The maintenance trends report is saved in PDF and stored in the Summary
Reports datastore
7. The Maintenance Summary Report is sent to the manager for evaluation
 User Identification
 Date Range
→ Maintenance Details
→ Transfer Data to Tableau
→ Generate Maintenance Summary
 Report PDF Stored
→ Pending Report Notice
1. Log-in credentials are not valid and must be re-authenticated
2. No data is available during the date range and the system will display the appropriate error message
Postconditions:
1. Work to be done on bicycle tracking statistics is recorded as in the Maintenance Expense Report
2. The Manager is notified about addendums to the main report and makes decisions to reduce repair related expenses
3. Safety maintenance measures are proposed to eliminate bicycle theft, destruction and accidents
Exceptions:
1. The system is offline due to connectivity issue or an update
2. There are no bicycle maintenance events associated with the selected date range
Summary:
User ID
Date Range
Report PDF
Analyst
Analyst
Summary Reports Datastore
Maintenance Details
Transfer Data
Generate Summary
Pending Report
Maintenance Datastore
Analyst
Analyst
Manager

17 | Page
Process Model:
Context Level DFD

19 | Page
Time Alerts Level 1 DFD – Christian Hernandez

20 | Page
Peak Routes System Level 1 DFD – Kaleb Parker

21 | Page
User Feedback System Level 1 DFD – Joseph Carusillo

22 | Page
Cost Tracking System Level 1 DFD – Amanda Blakley

23 | Page
Entity Relationship Diagram:

24 | Page
Data Dictionary and Metadata:
Entity Name: Time Tracking
Attribute PK Type Size Range Null? Comments/Validation
ALL_TripID Y Integer 16 0-999…9 N ###...# (00000000+1)
TT_BeginTime N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
TT_EndTime N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
TT_TimeRemain N Decimal(2,2) 5 60:00 – 00:00 N Starts at 60 min and counts down
ALL_RiderID N Character 10 n/a N U####-####
Entity Name: GPS
GPS_Key Y Character 32 N A hexadecimal value
ALL_TripID N Integer 16 0-999…9 N ###...# (00000000+1)
GPS_Longitude N Character 11 See Comments N +/-DD.MMSSSSS
GPS_Latitude N Character 11 See Comments N +/-DD.MMSSSSS
GPS_TimeStamp N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
Entity Name: Analysis (GPS)
AGPS_AnalysisID Y Character 32 N A hexadecimal value
ALL_TripID N Integer 16 0-999…9 N ###...# (00000000+1)
AGPS_StartPoint N Character 11 See Comments N +/-DD.MMSSSSS
AGPS_EndPoint N Character 11 See Comments N +/-DD.MMSSSSS
AGPS_RouteID N Integer 16 0-999…9 N ###...# (00000000+1)
Entity Name: Maintenence Service
MCT_MaintID Y Integer 8 0-999…9 N ###...# Starts at 0 add 1 per
MS_Expense N Decimal(3,2) 6 0-999.99 N
CU_ReportID N Integer 8 0-999…9 N ###...# (00000000+1)
CU_Timestamp N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
MS_WorkDone N Character 23 See Comments N +/-DD.MMSSSSS, +/-DD.MMSSSSS
All_BikeID N Integer 6 0-999999 N ###...# (000000+1)
Entity Name: Cost Tracking (Maintenence)
CU_Issue N VarChar 256 n/a Y
MCT_MaintID N Integer 8 0-999…9 N ###...# Starts at 0 add 1 per
MCT_Routine N Boolean 1 0,1 N True or False
MCT_ExpenseID Y Integer 8 0-999…9 N ###...# (00000000+1)
MCT_Expense N Decimal(3,2) 6 0-999.99 N
UF_Timestamp N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
ALL_BikeID N Integer 6 0-999999 N ###...# (000000+1)

25 | Page
Entity Name: User Feedback
UF_Name N VarChar 32 n/a N Only letters and symbols
UF_Timestamp N Timestamp 19 n/a N YYYY-MM-DD-HH-MM-SS
ALL_RiderID N Character 10 n/a N U####-####
CU_ReportID Y Integer 8 0-999…9 N ###...# (00000000+1)
CU_Location N Character 23 See Comments N +/-DD.MMSSSSS, +/-DD.MMSSSSS
ALL_BikeID N Integer 6 0-999999 N ###...# (000000+1)
CU_Issue N VarChar 256 n/a Y
Entity Name: Feedback Account
ALL_RiderID Y Character 10 n/a N U####-####
FA_Password N VarChar 32 8-32 N Must contain 1 capital &1 lowercase
letter, and 1 symbol. Only ASCII
characters
FA_Email N VarChar 64 See Comments N Must be a reachable email address

26 | Page
MILESTONE 3
Interaction Screens:
Input Screens
Peak Route Input Screen

27 | Page
User Feedback Input Form

28 | Page
Maintenance Service Input Screen

29 | Page
Output Screen
Peak Routes Input Screen

30 | Page
User Feedback Output Form

31 | Page
Maintenance Service Summary Report Output

32 | Page
Printed Report with Data

33 | Page
Testing:
Test Module Summary:
The testing that occurred went over the scope of the inputs for the User Feedback Form. The testing went over
the different input forms to ensure that they accepted the correct types of data inputs and rejected inputs that were
outside expected parameters. For each field in the form a variety of inputs including both inputs to be accepted and
rejected were introduced to check that the filters were operating. For each of the tests we first used an input that
should be accepted and then several variations of inputs to be rejected, all tests were passed. This is very promising for
the rest of the project because it shows that the ranges for the data in place are operating as expected which allows us
to proceed in developing the remainder of the input forms.
Test Plan:
Test Plan Page 1 of 3
Program ID:____UFB1___ Version Number _____2____
Tester: ___Kaleb Parker_______ Date Designed: ____4/15/2018__ Date Conducted: ______4/26/2018_____
Results:  Passed  Open items:
Test ID: ____1_____ Requirement addressed: ___Ability to submit User Feedback____
Objective: ___Ensure that user can enter first name on to User Feedback Form________
Field/Control Tested: ____First Name_____________________________________________________________
Value Entered Expected Results Actual Results Passed(Y/N)
John Accepted Accepted Y
J0hn ERROR: Invalid Input ERROR: Invalid Input Y
j0^h_n/> ERROR: Invalid Input ERROR: Invalid Input Y
“ “ ERROR: Null Input Not Accepted ERROR: Null Input Not Accepted Y
Test Plan
Objective: ____Ensure that user can enter last name on to User Feedback Form________
Field/Control Tested: ____Last Name____________________________________________________________
Doe Accepted Accepted Y
D03 ERROR: Invalid Input ERROR: Invalid Input Y
9D03^kh ERROR: Invalid Input ERROR: Invalid Input Y

34 | Page
Test Plan
Objective: ___Ensure that user can enter U Number on to User Feedback Form________
Field/Control Tested: ____”U Number”________________________________________________________
U1234-5678 Accepted Accepted Y
Ul2E4-567H ERROR: Invalid Input ERROR: Invalid Input Y
NhI3453$$> ERROR: Invalid Input ERROR: Invalid Input Y
Objective: __Ensure that user can check the “will you use…” on to the User Feedback Form._______
Field/Control Tested: ____”Future Use”_______________________________________________________
Yes Accepted Accepted Y
No Accepted Accepted Y
Undecided Accepted Accepted Y
Test Plan
Objective: __Ensure that user can check “how many times they used” on to User Feedback Form________
Field/Control Tested: ____”How many times have you used…”______________________________________

35 | Page
1 Accepted Accepted Y
5+ Accepted Accepted Y
Test Plan
Objective: __Ensure that user can select the “Rating” on to the User Feedback Form._______
Field/Control Tested: ____”Rate your experience”_______________________________________
Poor Accepted Accepted Y
Fair Accepted Accepted Y
Good Accepted Accepted Y
Excellent Accepted Accepted Y
Objective: __Ensure that user can input additional comments on to User Feedback Form________
Field/Control Tested: ____”Additional Comments”__________________________________________
“I really…” Accepted Accepted Y
“agunawlrgun” Accepted Accepted Y
id=$id Failed Failed Y
!@#$%%^ Failed Failed Y

36 | Page
Implementing the New System:
Conversion Strategy
The Implementation
It is crucial that the new Share-A-Bull Bikes system be implemented with a minimal amount of time, delays, failures and
expenses involved. After discussions regarding the steps needed to convert the system, we have concluded that a
simultaneous strategy is the preferred method. The implementation process will occur during the 2018 Summer session
throughout all three University of South Florida campuses (Tampa, Saint Petersburg and Sarasota-Manatee). Although
there is a potential for increases in training and associated costs, the simultaneous approach will allow analysts to detect
a larger amount of errors and anomalies within the system in a relatively short period of time.
Preparation for Transition
Prior to the simultaneous conversion process, it is essential that all tasks are clearly laid out and subsequently
completed. This will involve the preparation of technology, staff, and maintenance prior to June 1st
, 2018.
The Technology
The three phases in preparing the technology for conversion are hardware installation, software installation and data
conversion. Firstly, engineers and consultants will ensure that all computers and associated devices are connected to the
server and internet for easy access to the Share-A-Bull system. Next, our software engineers and analysts will work side-
by-side with vendors of packaged software in order to safely install all components onto USF’s computer network. An
experienced Project Manager will communicate any errors to the vendor. Finally, it is imperative to convert all existing
data into the newly constructed system. These phases will be completed in time for the launch of the “to be” system.
The Staff
Aside from phasing in the technology, it is also important to prepare both old and new Information Technology staff for
the upcoming conversion. The staff will be provided with extensive training on the new Share-A-Bull Bikes system and
instructed to properly deal with any errors that may occur during the transition process. This will involve weekly training
sessions for eight weeks prior to the summer launch. In addition, on-site training will continue on a monthly basis when
the system is fully implemented.

37 | Page
Maintenance
There will also be specific training provided for the maintenance staff. This is because the maintenance staff is
imperative to the smooth transition from the old system to the new system and will need to quickly fix both hardware
and software errors with patches and updates. Maintenance staff will complete four of the eight weeks in IT training and
will also be provided a clear, open communication path to both the Project Manager and the vendor of existing
packaged software purchased by USF.
Contingency Plan
Although it is anticipated that there will be a minimal amount of problems associated with the implementation of the
back-end changes to the Share-A-Bull Bikes system, USF’s brightest business analysts have put into place a contingency
plan. The plan accounts for increased staff during the initial months of the conversion process as well as a wide support
service that will be operational twenty-hours a day, seven days a week.
Advantages Disadvantages
• Short Implementation Timeframe • Higher Amount of Risk Due to No Back-up
• Ability to Detect More Errors • More Extensive Training
• Greater Amount of Flexibility in
Summer
• Increased Cost Due to Larger Staff
Although there are number of advantages to implementing the new system simultaneously across all campuses, there
are a few disadvantages as well. While there is a shorter amount of time associated with the conversion than in other
strategies, there is a higher risk involved with errors. If the system is unable to handle traffic and crashes, according to
the contingency plan the system will pulled offline for maintenance. This is because the old system will no longer exist.
Also, as stated above, there is a higher associated cost due to extensive training of a larger amount of staff who must
work more hours in the initial months.

38 | Page
Please review the following grading/checkoff sheet to ensure all deliverables are
included before submission.
Grading/Checkoff Sheet – Milestone 3/Final Report
I. REVISED MILESTONE 1 & 2 ............................................................................... _____
II. DESIGN
a. Example Input Screen.................................................................................. _____
i. Fields validated, Default values, Annotated properly
ii. Shows three main areas (Navigation, body, status)
iii. Consistent with ERD
b. Example Output Screen ................................................................................ _____
i. Annotated properly
ii. Consistent with ERD
c. ONE example printed summary report with example data .......................... _____
i. Annotated properly
ii. Consistent with ERD
III. IMPLEMENTATION
a. Test Plan with Summary...................................................................................... _____
b. Conversion Strategy............................................................................................. _____

39 | Page
Meeting Minutes: Team Earthworm #6
Date and Time of Meeting: 4/19/2018 @ 2:00 PM
Attendees:
Kaleb Parker, Christian Hernandez, Amanda Blakley, and Joseph Carusillo
Who did not attend and why?
Every member was in attendance.
Summary of Meeting:
• Assigned Input Screens to Amanda
• Assigned Output screens to Christian
• Assigned revision of interview questions to Joseph
• Assigned Revision of Pert & Gantt Chart to Kaleb
Meeting Minutes: Team Earthworm #7
Date and Time of Meeting: 4/23/2018 @ 4:00 PM
Attendees:
Kaleb Parker, Christian Hernandez, Amanda Blakley, and Joseph Carusillo
Who did not attend and why?
Every member was in attendance.
Summary of Meeting:
• Overview and examination of previously assigned work
• Assigned Printed Report to Amanda
• Assigned Text plan to Kaleb
• Assigned Conversion Strategy to Kaleb
Interview Survey:
This is the link to the Google Survey that corresponds to the Interview Report section:
https://goo.gl/forms/IMuVppSPiKahM5Uj1

Systems Analysis & Design Project

More Related Content

Similar to Systems Analysis & Design Project (20)

Recently uploaded (20)

Systems Analysis & Design Project