Tangipahoa Transportation System
Project for Levar James
Team 1 Members:
Whitney Capone
James McCoy
Kimberly Palmer
Miranda Palmisano
ISDS 4125
FALL 2013
10/24/2013
Table of Contents
Executive Summary.............................................................................................................................................. 3
Recommended Acquisition Strategy…………………………………………………………………….….……… 4
Alternative Matrix………………………………………………………………………………………………….……… 5
Architecture Design……………………………………………………………………………………………...……...6-7
Hardware and Software Specifications…………………………………………………………………………….8
Interface Structure Design………………………………………………………………………………………………9
Interface Design……………………………………………………………………………………………...….……10-15
System Request ....................................................................................................................................................16
Statement of Work ..............................................................................................................................................17
Work Plan...............................................................................................................................................................18
Feasibility Analysis .............................................................................................................................................19
Requirements Definition ..................................................................................................................................20
Use Cases…………. ....................................................................................................................................... ...21-23
Program Design Specifications……………………………….…………………………………..………….....24-29
Physical Process Model……………………………………………………………………………………………30-33
Physical Data Model……………………………………………………………………………………………………...34
CRUD Matrix…………………………………………………………………………………………………………………35
Storage Design…………………………………………………………………………………………...…………………36
Migration Plan…………………………………………………………………………………………...…………………37
Change Management Plan ……………………………………………………………………….....…………………38
System Conversion Strategy………………………………………………………………………………………….39
Test Plans…………………………………………………………………………………………...…….……….….…40-49
Training Plan…………………………………………………………………………………………...……………...……50
Problem Report…………………………….…………………………………………………………...…………………51
Time Cards………………………………………………………………………………………………………………52-56
2
Executive Summary
The Tangipahoa Transportation System is devoted to
providing safe, reliable, caring and courteous service to its students,
parents, school administrators and the community through the
cooperative efforts of well-trained, dedicated professionals. In
order to provide better organization and communication for the
employees at Tangipahoa Transportation System, our team is
proposing the creation of a new Access database. The database will
be available for any approved employee at Tangipahoa
Transportation System. The new system will house a switchboard
that links users to all reports, queries, and tables. For convenience,
users will be able to access data in one centralized location and print
and send any reports within minutes.
Our target audience for this Access database is the
administrative staff at Tangipahoa Transportation System. Although
this database will be able to grow and expand into other parish
systems in the future, our scope for this project is intended
specifically for the Tangipahoa Transportation System. Our team is
committed to providing a quality solution for the gap between data
and Tangipahoa Transportation System. We believe that Microsoft
Access will provide a perfect bridge for that gap. Since the
administrative staff is already familiar wit how to use Access, the
database will provide a similar user interface with an easy-tonavigate design.
Today, in order to access bus route information, users must
search through endless file cabinets or excel documents. There is no
one centralized location for all of the information. There is no easy
way to send reports and lists of information, which creates a large
wait time for bus routes. A Microsoft Access database will solve
these problems and open up countless possibilities for users to
manage their workload and access information at their fingertips.
3
Recommended Acquisition Strategy
For the Tangipahoa Parish Transportation System, our group
has concluded that it would be best to develop an in-house custom
application instead of purchasing a packaged option. Firstly, we
believe that the Tangipahoa Parish Transportation System is in need
of fixing data redundancy. Currently, employees are accessing
multiple spreadsheets in Microsoft Excel that contain similar data.
By using a customized application, our team will be able to create a
program that will best suit our customer’s needs. The system will
be centralized which is one of Levar’s requests and it will increase
efficiency for Levar’s team.
After looking at many alternative software packages, we
decided to use some of the ideas that we found and place it in our
custom application. For example, InfoPath 2010 has the capabilities
to provide cascading dropdown menus based on users preference
selections. We will provide this type of capability in our design.
Currently, our team possess’ many skills that are needed in
order to create the custom system. Each teammate has worked for
multiple companies in the Information Technology department,
which has prepared us to take on an assignment such as this. Our
team possess’ both technical and functional skills such as project
management, time management, creativity, SQL, VB.NET, Access, etc.
We are completely confident in our abilities to successfully complete
this custom application in a timely manner.
4
Alternative Matrix
Evaluation
Criteria
Relative
Importance
(Weight)
Alt 1: Access
Database
Score
(1-5)
Wtd
Score
Alt 2: VB
Application
Score
(1-5)
Wtd
Score
Alt 3: Web
Interface ASP
Score
(1-5)
Wtd
Score
15
Little interest in
developing inhouse skills
1
15
1
15
Developed in VB
and Java. No inhouse interest in
developing skills
1
15
Integration with
existing system
15
3
45
4
60
More difficult to
integrate with
existing data
2
30
Experience with
product
10
Easy to pull
existing
spreadsheets out
of excel and into
Access
Users have a little
familiarity with
this product.
Developed using
Access and VB.
Little interest in
developing inhouse skills.
Easy to integrate
information from
Excel to VB.
2
20
Users are not
familiar with this
product.
2
20
No experience
1
10
25
No initial charge
5
125
No initial charge
5
125
May have a
charge
2
50
15
Program is
already in use at
their facility
Yes – switchboard
5
75
5
75
30
80
5
100
Company does
not have
experience
Would need
experience to
customize
2
4
Program used by
other companies
as well as IT sector
Easy to customize
4
80
Technical
Issues:
Develops
desirable inhouse skills
Economic
Issues:
Cost
Organizational
Issues:
Demonstrated
product in
market
Customizable
interface
TOTAL
20
100
360
395
215
5
Architecture Design
Our application will use a client-server architecture design as shown in the diagram
below.
1. Operational Requirements
Technical Environment
1.1 The system will work by accessing the Visual Basic application that is
linked to an Access database
1.2 Customers will need only Windows or Mac operating system and/or
Visual Studios
System Integration
1.3 The application will read information from the Access database, which
contains basic information about transportation (e.g., Driver, Bus, ID,
Route).
1.4 The application system will write information to the database.
1.5 The system will need to remain current with evolving Web standards and
Visual Studio standards.
1.6 No special maintainability requirements anticipated.
Portability
Maintainability
6
Architecture Design
2. Performance Requirements
Speed
Capacity
Availability and
Reliability
2.1 Response time must be less than 10 seconds.
2.2 There will be a maximum of 10 simultaneous users at peak use times.
2.3 The system should be available 24/7.
2.4 The system shall have 99% uptime performance.
3. Security Requirements
System Value
Access Control
Encryption/Authenticati
on
Virus Control
3.1 Access to the application will be restricted to authenticated users.
3.2 Users can access the application with username and password from Active
Directory
3.3 No encryption required
3.4 Downloads must be verified as virus free
4. Cultural and Political Requirements
Multilingual
Customization
Unstated Norms
Legal
4.1 No special multilingual requirements anticipated
4.2 No special customization requirements are anticipated.
4.3 No special unstated norm requirements are anticipated.
4.4 Sensitive information such as birthday, drivers license number, SSN will
be secure.
7
Hardware and Software Requirements
Operating System
Special Software
Hardware
Network
Client
Windows Vista or Higher
Microsoft Office 2008
Microsoft Visual Studio 2008
Middle range Windows
computer capable of
supporting Microsoft Office
2008
Broadband or Dial-up
Server
Windows Vista or Higher
Microsoft Access 2008
Windows Server capable
of running Microsoft
Access 2008
Dual 100 Mbps Ethernet
8
Interface Structure Design
0
Main Menu
1.1
1
Accident Report
1.1.1
2
Driver Information
1.1.2
3
Bus Information
1.1.3
4
Maintenance
1.1.4
5
Requirement
1.1.5
9
Interface Design
10
Interface Design
11
Interface Design
12
Interface Design
13
Interface Design
14
Interface Design
15
System Request
REQUESTED BY: Miranda Palmisano
ORGANIZATION: Tangipahoa Transportation System
ADDRESS: 59656 Puleston Road Amite, LA 70422
CONTACT: LeVar James – 985-748-2423
TYPE OF SYSTEM:
[X] New System
[ ] System Enhancement
[ ] System Error Correction
DATE: September 25, 2013
URGENCY:
[ ] Immediate – Operations are impaired or opportunity lost
[ ] Problems exist, but can be worked around
[X] Business losses can be tolerated until system installed
PROBLEM STATEMENT:
A business problem that our client is encountering is that there is no one system in place where
transportation data can be retrieved. Right now, employees have to search through multiple excel
files containing the correct data, or search through file cabinets to find printed information. Since
there is many different excel files and methods of data entry, there is also redundant data. In
response to this issue, Team 1 has created an access database that allows employees of Tangipahoa
Transportation System to easily retrieve all necessary data from one easy location.
SERVICE REQUEST:
Team 1 intends to approach this problem by taking a very close look at the Tangipahoa
Transportation System (TTS) data and develop a system that can help employees access and update
their data quickly and efficiently. We intend on creating an access database that will house all
necessary information and allow all approved employees to access the database to suit their
information needs. This eliminates the use of having to navigate through multiple excel files as well
as file cabinets with printed documentation. In addition, the new system will have certain
functionalities that are not currently available to TTS employees. Firstly, the system will display a
switchboard that will allow users to navigate the database with ease. Also, the system will have the
option of printing reports and searching through current data. This system should result in higher
employee satisfaction and a more organized data retrieval process.
IS LIAISON: Whitney Capone, James McCoy, Kimberly Palmer and Miranda Palmisano
SPONSOR: Carolyn Borne
--------------------------TO BE COMPLETED BY SYSTEMS PRIORITY BOARD-----------------------[ ] Request approved Assigned to: _____________________________ Start date:
________________________________
[ ] Recommend Revision
[ ] Suggest user development
[ ] Reject for reason:
_________________________________________________________________________________________
16
Statement of Work
Statement of Work:
 Project Name:
Tangipahoa Transportation System
 Project Manager:
 Customer:
LeVar James
 Project Start/End Date (Projected):
9/25/2013 – 12/9/2013
 Development Staff Estimates (man-months):
Programmers:
1.0
Application Designers:
1.0
Database Manager:
1.0
............................................................................................
Total:
3.0
Product Description:
Goal
 The aim of the project is to implement an effective and efficient Access database that will
better accommodate the Tangipahoa Transportation System (TTS) in accessing data and
reports.
 Our Access database will be specifically designed to handle the TTS information, which
will optimize performance while providing fast data retrieval to current employees.
Objective
 More user friendly oriented data retrieval
 One centralized data repository
 Design an app specific to Tangipahoa Transportation System
 Reduce redundant data
Phases of Work:
The following tasks and deliverables reflect the current understanding of the project:  In Analysis, an Access database will be created to benefit the Tangipahoa Transportation
System employees.
 In Design, Team 1 will showcase an interface that will be more user-friendly than current
model.
 In Implementation, Team 1 will allow users to access and update current information in the
system. Users will also be able to create new reports, print reports and send reports via
web.
17
Work Plan
Task
ID
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.7.1
1.7.2
1.7.3
1.7.4
1.8
1.9
1.10
1.11
1.12
2
2.1
2.1.1
2.1.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Task Name
Planning &
Analysis Phase
Cover Page
Table of
Contents
Executive
Summary
Work Plan
System Request
Feasibility
Analysis
Requirements
Definition
Functional
Non-Functional
As-Is System
Improvements
Use Cases
Process Models
Data Models
DFD’s
ERD’s
Design Phase
Enter data into
Access
database
Create tables
Create access
relationships
Create interface
in VB
Alternative
Matrix
Architecture
Design
Hardware and
Software
specifications
Physical
Process Model
Program
Design
Specifications
Physical Data
Model
Updated CASE
repository
CRUD Matrix
Put all
documents
together
Data storage
design
Assigned
To
Duration
(Hours)
Estimated
Start Date
Finish Date
Start Date
Actual
Finish Date
Duration
(Hours)
Status
Open
Miranda
Miranda
.25
.25
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
.10
.10
Complete
Complete
Miranda
.75
9/22/2013
9/22/2013
9/23/2013
9/23/2013
.50
Complete
Miranda
Miranda
Miranda
1.0
.50
1.5
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
.75
.50
1.0
Complete
Complete
Complete
James
1.0
9/22/2013
9/22/2013
9/22/2013
9/22/2013
1.0
Complete
James
James
James
James
Kimberly
Kimberly
Kimberly
Whitney
Whitney
.25
.25
.25
.25
1
.5
.5
1
1
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
.25
.25
.25
.25
1
.5
.5
1
1
Miranda
.75
10/20/2013
10/20/2013
10/20/2013
10/20/2013
.75
Complete
Complete
Complete
Complete
Complete
Complete
Complete
Complete
Complete
Complete
Complete
Miranda
Miranda
.30
.15
10/20/2013
10/20/2013
10/20/2013
10/20/2013
10/20/2013
10/20/2013
10/20/2013
10/20/2013
.30
.15
Complete
Complete
James
3.0
10/20/2013
10/20/2013
10/20/2013
10/20/2013
3.0
Complete
Miranda
.25
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.25
Complete
Miranda
.10
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.10
Complete
Whitney
.50
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.50
Complete
Whitney
1
10/23/2013
10/23/2013
10/23/2013
10/23/2013
1
Complete
James
.25
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.25
Complete
Whitney
.50
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.50
Complete
Whitney
.25
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.25
Complete
Kimberly
Kimberly
.50
2.0
10/23/2013
10/23/2013
10/23/2013
10/23/2013
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.50
2.0
Complete
Complete
Miranda
.50
10/23/2013
10/23/2013
10/23/2013
10/23/2013
.50
Complete
18
Feasibility Analysis
19
Requirements Definition
Functional Requirements
User Input
 The system must allow users to input data into the database including reports and tables.
 The system must allow input of bus maintenance and repair information.
 The system must allow input of driver information.
 The system must allow input of route information into the system.
User Output
 The system must allow users to view reports, queries, and tables.
 The system must allow users to output reports and tables.
System History
 The system must retain database information for three years.
Nonfunctional Requirements
Operational
 The system must be compatible with Microsoft Access 2010 and 2013.
 The system should integrate with the current database system.
Performance
The system must connect and maintain connection to a Access database.
The system will update database information in real time.
Security
 The system can only be accessed by administrative approved devices.
 The system must be on a password protected device.
As-Is



The user currently accesses data via filing cabinets or via multiple excels files.
Data redundancy due to non-centralized system.
Improvements





The new system will be one centralized data repository with reduced data redundancy.
The interface will be more user-friendly due to switchboard
Users will be able to create new reports, print reports, and send reports via web.
Users will be able to access up-to-date information.
Users will be able to search through current data to efficiently locate current data.
20
Use Cases
System
21
Use Cases
Tangipahoa Transportation system
Author (s): __Kimberly Palmer__
Date:
9-25-13
USE CASE NAME:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
Sends Information
User
DESCRIPTION:
This use case describes the addition of data from one of four
possible actors to the main Tangipahoa transportation system
database. The four different actors input specific information that is
available to them. The system is then updated with the new
information.
There is no precondition requirement for inputting data
This use case is initiated when an actor submits information to be
added to the database.
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:



Bus
Driver
Route
Actor Action
System Response
Step 1:
Step 2:
Actor submits information to be
added to the system
System receives information and updates
the database
ALTERNATE COURSES:
There is only one course for inputting new information
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
The use case is concluded when the information is added to the database
There are no post condition requirements.
There are no business rules that must be followed to allow for the input of data
The User will be using an access database and a web form. The other three
actors will be using a web form.
OPEN ISSUES:
Those who are inputting the data are doing it correctly and have the correct
credentials
None
22
Use Cases
Tangipahoa Transportation system
Author (s): __Kimberly Palmer__
USE CASE NAME:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
Date:
9-25-13
Requests Information
User
None
This use case describes the user requesting information from the
Tangipahoa transportation system database. This use case only
involves one actor the user, but there are multiple data request that
the actor can make from the system
The request must be made within the rules for queries or reports
This use case is initiated when an actor submits a request for
information from the database.
Actor Action
System Response
Step 1:
Step 2:
Actor requests information from
the system about the data it
stores
System receives the request and responds
to it by sending the requested information to
the user
ALTERNATE COURSES:
There is only one course which is noted above
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
The use case is concluded when the user receives the information
There are no post condition requirements
There are no business rules that must be followed to allow for the requesting of
data
The User will be using an access database or a web form to request the
information as well as to view the information requested
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
Those who are requesting the data are doing it correctly and have the correct
credentials
None
23
Program Design Specifications
Name: Menu
Purpose: Allows for navigation within the system giving users access to the Accident
Report form, the Driver form, the Bus form, the Maintenance form, and the Requirements
form.
Programmer: Team Last Semester
Due Date: October 31, 2013
Code: Visual Basic
Event
Accident Report button
Driver Information button
Bus Information Button
Maintenance Button
Requirement Button
System opens Accident Report page
System opens Driver page
System opens Bus page
System opens Maintenance page
System opens Requirement page
Input Name
N/A
Type
N/A
Used By
N/A
Notes
N/A
Output Name
N/A
Type
N/A
Used By
N/A
Notes
N/A
Pseudocode:
If btnAccident is clicked
Then open Accident Report form
If btnDriverInformation is clicked
Then open Driver form
If btnBusInformation is clicked
Then open Bus form
If btnMaintenance is clicked
Then open Maintenance form
If btnRequirement is clicked
Then open Requirement form
24
Program Design Specifications
Name: Accident Report
Purpose: Allows user to submit necessary information for an accident report
Programmer: Team Last Semester
Due Date: October 31, 2013
Code: Visual Basic
Event
Add Button Clicked
Delete Button Clicked
Save Button Clicked
Submit Button Clicked
Exit Button Clicked
Tangipahoa Parish Picture Button Clicked
Output
System creates blank Driver Information form
System deletes current Driver Information
displayed
System saves current Driver Information
displayed
System saves current Driver Information
displayed
System closes program
System opens Menu page
Input Name
txtAccidentID
txtAccidentDesc
txtBusTagID
dateAccidentDate
dateDateReviewed
txtPoliceComplaintNum
txtTotalStudentsInj
cmbDriverID
txtDriverLName
txtDriverFName
dateHireDate
cbDriverStatements
Type
String(25)
String (25)
String(25)
DateTime
DateTime
String(25)
String(25)
ComboBox
String(25)
String(25)
DateTime
CheckBox
Used By
System User
System User
System User
System User
System User
System User
System User
System User
System User
System User
System User
System User
cbTrinity
CheckBox
System User
cbPreventable
cbTotalVeh
cbFixedObject
cbPropertyOnly
CheckBox
Checkbox
Checkbox
Checkbox
System User
System User
System User
System User
Output Name
Accident_Report
Type
DataGrid
Used By
System User
Notes
Accident ID Number
Description of Accident
Bug Tag ID Number
Date of Accident
Date Accident was Reviewed
Police Complaint Number
Total Number of Students Injured
Driver ID Number
Driver Last Name
Driver First Name
Driver Hire Date
Driver Statements Completed
(Yes/No)
Accident Report Sent to Trinity
(Yes/No)
Accident Preventable(Yes/No)
Total W/ Other Vehicles(Yes/No)
Fixed Object Hit (Yes/No)
Property Only (Yes/No)
Notes
Shows the Driver Information Spreadsheet
Pseudocode:
IF Add Button clicked
Then open blank Driver form
IF Delete button clicked
25
Program Design Specifications
Then Delete Driver displays
IF Save Button clicked
Then current Driver saves
IF Submit Button clicked
Then current Driver saves
IF Exit Button clicked
Then program closes
IF Tangipahoa Parish Picture Button clicked
Then Menu page opens
26
Program Design Specifications
Name: Driver
Purpose: Allows user to add new driver information, edit driver information, and view
driver information
Programmer: Team Last Semester
Due Date: October 31, 2013
Code: Visual Basic
Event
Add Button Clicked
Delete Button Clicked
Exit Button Clicked
Tangipahoa Parish Picture Button Clicked
Output
System creates blank Driver Information form
System deletes current Driver Information
displayed
System saves current Driver Information
displayed
System saves current Driver Information
displayed
System closes program
System opens Menu page
Input Name
cmbDriverID
Type
String(25)
Used By
System User
txtLastName
txtFirstName
dateHireDate
txtPhoneNumber
cmbClassification
String (25)
String(25)
DateTime
String(10)
String(25)
System User
System User
System User
System User
System User
Output Name
Driver_Report
Type
DataGrid
Used By
System User
Save Button Clicked
Submit Button Clicked
Notes
Allows user to select
Driver ID
Driver Last Name
Driver First Name
Driver Hire Date
Driver Phone Number
Driver Classification
Notes
Shows the Driver
Information
Spreadsheet
Pseudocode:
IF Add Button clicked
Then open blank Driver form
IF Delete button clicked
Then Delete Driver displays
IF Save Button clicked
Then current Driver saves
IF Submit Button clicked
Then current Driver saves
IF Exit Button clicked
Then program closes
IF Tangipahoa Parish Picture Button clicked
Then Menu page opens
27
Program Design Specifications
Name: Maintenance
Purpose: Allows for navigation within the system giving users access to the Accident
Report form, the Driver form, the Bus form, the Maintenance form, and the Requirements
form.
Programmer: Team Last Semester
Due Date: October 31, 2013
Code: Visual Basic
Event
Add Button Clicked
Delete Button Clicked
Save Button Clicked
Submit Button Clicked
Exit Button Clicked
Tangipahoa Parish Picture Button Clicked
Output
System creates blank Maintenance form
System deletes current Maintenance displayed
System saves current Maintenance displayed
System saves current Maintenance displayed
System closes program
System opens Menu page
Input Name
txtTagID
txtReportNum
txtTypeNum
txtTypeDes
Type
String(25)
String (25)
String(25)
String(25)
Used By
System User
System User
System User
System User
Notes
Bus Tag ID
Report Number
Type of maintenance
Description of
maintenance
Output Name
Maintenance_Report
Type
DataGrid
Used By
System User
Notes
Shows the
Maintenance
Spreadsheet
Pseudocode:
IF Add Button clicked
Then open blank Maintenance form
IF Delete button clicked
Then Delete Maintenance displays
IF Save Button clicked
Then current Maintenance saves
IF Submit Button clicked
Then current Maintenance saves
IF Exit Button clicked
Then program closes
IF Tangipahoa Parish Picture Button clicked
Then Menu page opens
28
Program Design Specifications
Name: Requirements
Purpose: Allows for navigation within the system giving users access to the Accident
Report form, the Driver form, the Bus form, the Maintenance form, and the Requirements
form.
Programmer: Team Last Semester
Due Date: October 31, 2013
Code: Visual Basic
Event
Add Button Clicked
Delete Button Clicked
Save Button Clicked
Submit Button Clicked
Exit Button Clicked
Tangipahoa Parish Picture Button Clicked
Output
System creates blank Requirements form
System deletes Requirements displayed
System saves current Requirements displayed
System saves current Requirements displayed
System closes program
System opens Menu page
Input Name
txtRequirementNum
txtDesc
Type
String(25)
String (25)
Used By
System User
System User
txtFormID
txtDriverID
String(25)
String(25)
System User
System User
Output Name
Requirements
_Report
Type
DataGrid
Used By
System User
Notes
Requirement Number
Description of
Requirement
Form ID
Driver ID
Notes
Shows the
Requirements
Spreadsheet
Pseudocode:
IF Add Button clicked
Then open blank requirements form
IF Delete button clicked
Then Delete requirements displays
IF Save Button clicked
Then current requirement saves
IF Submit Button clicked
Then current requirement saves
IF Exit Button clicked
Then program closes
IF Tangipahoa Parish Picture Button clicked
Then Menu page opens
29
Physical Process Model
30
Physical Process Model
31
Physical Process Model
32
Physical Process Model
33
Physical Data Model
34
CRUD Matrix
35
Storage Design
For our application’s storage format, we will be using a relational database since the data in
the system is mostly simple and not too complex. Relational databases also are mature
enough to support transactional systems. So this will be useful for our reports sections and
making sure that we can retrieve the right data to build out these reports. This system
should be able to support the Tangipahoa Transportation System for many years to come.
They have a few excel spreadsheets as of right now, making up 6 tables and a few thousand
rows. Of course, most of this information is redundant so a cleanup of the data will be
necessary. This application will be a great model for other parishes to use as well in the
future.
Data
Type
Use
Suggested
Format
Employee
Information
Bus Information
Simple (text
and numbers)
Simple (text
and numbers)
Simple (text
and numbers)
Simple (text
and numbers)
Simple (text
and numbers)
Transaction
Processing
Transaction
Processing
Transaction
Processing
Transaction
Processing
Transaction
Processing
Relational
DBMS
Relational
DBMS
Relational
DBMS
Relational
DBMS
Relational
DBMS
Accident
Information
Maintenance
Information
Requirements
Information
Approximate
Number of
Rows in DB
1000 rows
1000 rows
100 rows
500 rows
100 rows
36
Migration Plan
Preparing the Business
Conversion Strategy: Direct Conversion,
Simultaneous and Whole system
Prepare a business contingency plan
Preparing the
Technology
Install software
Preparing the People
Convert data
Assess costs and benefits
Motivate adoption
Conduct training
Revise management policies
Shown in the table above is our migration plan for this project. In our migration
plan, we chose to implement a direct conversion for our conversion style since our changes
will be made abruptly. This will instantaneously replace the old system that the
Tangipahoa Parish Transportation System is currently using. Secondly, for the conversion
locations we will implement the simultaneous conversion since this system will only be
used at the Tangipahoa Parish Transportation department. Finally, we will use the wholesystem conversion module. We will be installing the entire system at one time since it is
simple and straightforward.
For preparing the technology, the hardware is already installed at the
transportation department. Users are already set up with the appropriate computer
systems. In order for users to use the system, they will need to install the correct software,
which are Microsoft Access and Visual Studio. The department has already installed
Microsoft Access so the next step will be installing Visual Studio. After the correct
installations have taken place, our team will convert data from excel into access.
For preparing the people, there will be no need to revise management policies since
it is just a simple conversion. Secondly, the users will not need to assess costs and benefits
since this implementation and system is free of charge. Thirdly, Levar will need to
motivate adoption by showing users how they can accomplish their tasks and jobs more
efficiently. Finally, Levar will conduct one-on-one training since there is only a small
number of users that will be using this system.
37
Change Management Plan
For our change management plan, we expect Levar to be the
change agent and the sponsor for this change. Since there are only 7
adopters who will be using this system, many of them are ready for
the change to occur and are not resisting the new system
implementation. However, just in case there is some resistance, it
will be up to Levar to train the users one-on-one and actively
support and encourage the new system. After training the users, the
costs and benefits of the new system implementation will prove to
the new adopters that it is more beneficial to use the new system
rather than use the old system.
38
System Conversion Strategy
The conversion strategy we chose for this conversion is a direct simultaneous
whole-system strategy. There are three main parts to a conversion strategy. The first part
of the strategy is conversion style, which refers to how abruptly the change will be made.
We selected a direct type of conversion style, which means the switch from the old system
to the new system will be instantaneous. This choice to us a direct conversion style will
make the change simple, but it is also risky because there could be problems that weren’t
foreseen in the testing. With adequate planning and testing these problems and their
possible impact should be significantly mitigated.
The second aspect of a conversion strategy is the conversion location, or where this
system introduction will take place within the organization. We’ve chosen to use a
simultaneous conversion because of the organization’s size and system. A simultaneous
conversion occurs when the new system is installed at all locations simultaneously. When
the conversion is done this way there is no lack of uniformity amongst different units
within the organization because they are all converted to the new system at the same time.
A potential downside of the simultaneous conversion is that more staff will be needed to
install the system and train those who will be using the new system. This downside will
most likely be avoidable due to the size of the department and the relative simplicity of the
user interface of the new system.
The final part of the conversion strategy is the conversion modules or the extent of
the system that is initiated. For this part of the conversion strategy, we selected the wholesystem strategy we decided whole-system would be the right choice because of the
system’s straightforward nature. We felt it would be easiest to employ this strategy. The
conversion strategy as a whole is based on what we feel would be the easiest way to
implement the new
system. We came to these
decisions based on the
different conversion strategy
options as well as
the system specifications
and general
complexities of the
system.
Direct
Simultaneous
Whole-System
39
Test Plan
Test Stage
Web Interface
Unit tests
Integration tests
Black-box tests
User interface tests;
use scenario tests
Requirements tests;
usability tests
Alpha test; beta test
System tests
Acceptance tests
System
Management
Black-box tests
User interface tests;
use scenario tests
Requirements tests;
System Interfaces
Alpha test; beta test
Alpha test; beta test
Black-box tests
System interface
tests
Requirements tests;
40
Test Plan
Program ID: Menu Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
 Passed
Test ID: 1
Date conducted: 11/29/2013
☐ Open Items:
Requirement addressed: Main Menu
Objective:
Make sure all of the buttons on the main menu open the appropriate forms.
Test cases
Interface ID
1. Accident Report
2. Driver Information
3. Bus Information
4. Maintenance
5. Requirements
6. Driver Scorecard
Data Field
Button
Button
Button
Button
Button
Button
Value Entered
Clicked Button
Clicked Button
Clicked Button
Clicked Button
Clicked Button
Clicked Button
Script
Expected results/notes
-Each button should open the appropriate form.
Actual results/notes
-The menu is working properly. Each button opens the correct corresponding form.
41
Test Plan
Program ID: Accident Report Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
☐ Passed
when clicking the submit button.
Test ID: 2
Date conducted: 11/29/2013
☐ Open Items: Fix the Integer problem that is occurring
Requirement addressed: Accident Report Form
Objective:
Make sure all of the buttons on the Accident Report Form work as well as database
updates.
Test cases
Interface ID
1. Accident ID
2. Accident description
3. Bus Tag ID
4. Accident Date
5. Police Complaint #
6. Total Students Injured
7. Total Non- Students Injured
8. Driver ID
9. Main Menu
10. Submit
6. Exit
Data Field
Text box
Text box
Text box
Date
Text box
Text box
Text box
Text box
Button
Button
Button
Value Entered
1
Test
1
Saturday November 30, 2013
1
1
1
1
Clicked
Clicked
Clicked
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered.
Actual results/notes
-The menu button is working properly. The info tip was displayed.
-After entering values into all of the fields and clicking Submit, I received an integer
error. “Could not convert the string to integer”.
-The Exit button is working properly. The info tip was displayed.
42
Test Plan
Program ID: Bus Information Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Date conducted: 11/29/2013
Results:
☐ Passed
 Open Items: The Bus Make is not working properly. It is only
grabbing the first letter entered and then adding it to the database.
Test ID: 3
Requirement addressed: Bus Information Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Bus Tag ID
5. Bus Make
6. Driver ID
Data Field
Button
Button
Button
Label
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
Auto
TEST
3
Script
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered.
Actual results/notes
-The Bus Tag ID and Driver ID are working properly.
-The Bus Make is not working correctly. When I entered “TEST” it placed it in the
database as “T”.
-The buttons are all working properly. Each button opens the correct
corresponding form.
43
Test Plan
Program ID: Bus Information Form
Version number: 2
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
Test ID: 4
Passed
Date conducted: 11/29/2013
☐ Open Items:
Requirement addressed: Bus Information Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Bus Tag ID
5. Bus Make
6. Driver ID
Data Field
Button
Button
Button
Label
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
Auto
TEST
3
Script
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered.
Actual results/notes
-The Bus Tag ID and Driver ID are working properly.
-The Bus Make is now working correctly.
-The buttons are all working properly. Each button opens the correct
corresponding form.
44
Test Plan
Program ID: Driver Information Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Date conducted: 11/29/2013
Results:
☐ Passed
 Open Items: The Driver First/Last Name, Phone Number
and Classifcation are not working properly. It is only grabbing the first letter entered and
then adding it to the database.
Test ID: 5
Requirement addressed: Driver Information Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Driver Last Name
5. Driver First Name
6. Driver ID
7. Hire Date
8. Phone Number
9. Classification
Data Field
Button
Button
Button
Text Box
Text Box
Label
Date
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
Palmisano
Miranda
Auto
November 18, 2013
9857058835
TEST
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered.
Actual results/notes
-The Driver ID is working properly.
-After clicking Submit, it only submits the first character that I entered from the
Drivers Last Name, Drivers First Name, Classification and Phone Number.
-The buttons are all working properly. Each button opens the correct
corresponding form.
45
Test Plan
Program ID: Driver Information Form
Version number: 2
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
Passed
Test ID: 6
Date conducted: 11/29/2013
☐Open Items:
Requirement addressed: Driver Information Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Driver Last Name
5. Driver First Name
6. Driver ID
7. Hire Date
8. Phone Number
9. Classification
Data Field
Button
Button
Button
Text Box
Text Box
Label
Date
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
Palmisano
Miranda
Auto
November 18, 2013
9857058835
TEST
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered.
Actual results/notes
-The Driver ID is working properly.
-After entering information and clicking submit, everything is entered correctly to
the table/database.
-The buttons are all working properly. Each button opens the correct
corresponding form.
46
Test Plan
Program ID: Maintenance Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
Passed
Test ID: 7
Date conducted: 11/29/2013
☐ Open Items:
Requirement addressed: Maintenance Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Tag ID
5. Maintenance ID
6. Report Num
7. Type Num
Data Field
Button
Button
Button
Label
Text Box
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
1
1
1
1
Script
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered and saved in the table
below.
Actual results/notes
-All text boxes are working properly and are allowing info to be saved to the
database.
-The buttons are all working properly. Each button opens the correct
corresponding form.
47
Test Plan
Program ID: Requirements Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
Passed
Test ID: 8
Date conducted: 11/29/2013
☐ Open Items:
Requirement addressed: Requirements Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Form ID
5. Driver ID
6. Requirements Num
7. Requirements Desc
Data Field
Button
Button
Button
Label
Text Box
Text Box
Text Box
Value Entered
Clicked Button
Clicked Button
Clicked Button
Auto
1
1
test
Script
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered and saved in the table
below.
Actual results/notes
-All text boxes are working properly and are allowing info to be saved to the
database.
-The buttons are all working properly. Each button opens the correct
corresponding form.
48
Test Plan
Program ID: Scorecard Form
Version number: 1
Tester: Miranda Palmisano Date designed: 11/20/2013
Results:
Passed
Test ID: 9
Date conducted: 11/29/2013
☐ Open Items:
Requirement addressed: Scorecard Form
Objective:
Make sure all of the buttons on the main menu open the appropriate forms as well as
information entered into the text boxes update the database.
Test cases
Interface ID
1. Menu
2. Submit
3. Exit
4. Scorecard ID
5. School
6. Bus ID
7. Last Name
8. First Name
9. Physical
10. Physical
Data Field
Button
Button
Button
Label
Text Box
Text Box
Text Box
Text Box
Checkbox
Date
Value Entered
Clicked Button
Clicked Button
Clicked Button
Auto
LSU
1
Palmisano
Miranda
Checked
November 18, 2013
Expected results/notes
-The Main Menu button should open the Main Menu as well as display an info tip.
-The Submit button should submit the data that was entered and display it in the
table below. The Submit button should also display an info tip.
-The exit button should show an info tip and when clicked, it should exit the form.
-All of the text boxes should allow for data to be entered and saved in the table
below.
Actual results/notes
-All text boxes are working properly and are allowing info to be saved to the
database.
-The buttons are all working properly. Each button opens the correct
corresponding form.
49
Training Plan
The training plan that will be used is one-on-one training. Since there
is only a very small group of users that will be updating, adding, and deleting
items on the system, it is more beneficial for Levar to train the users to better
ensure that the users really do understand the material. The factors that we
considered before choosing a training plan were Cost to develop, cost to
deliver, impact and reach. Our costs to develop and deliver are low, our
impact is medium and our reach is low. These factors helped us decide that
one-on-one training was the most beneficial.
50
Project Assessment
Our project assessment is provided to help Levar and his team
understand what was successful about our project and what can be improved
upon in the future. Listed below is the team review as well as the system
review.
After reviewing all of the team member’s documentation that analyzed
his/her performance, we came up with the following summary that will help
on performance improvement in the future. To improve performance, our
team discussed it would be beneficial to meet at least three times a week in
order to keep communication flowing throughout the team. This was one of
our team downfalls throughout this project. We did not meet enough to
discuss and communicate on what could be improved and what was going on
with the project. Secondly, follow the teamwork plan more closely. By
having a set list of tasks and milestones to complete, it would help us stay
focused and on track. We vaguely used the work plan that could have
hindered our performance since we waited till the last minute to complete
most of the tasks. Thirdly, after each milestone, it would be beneficial to
capture lessons learned. This will help us improve which things we need to
work on before moving on to the next phase of the project. Finally, using the
FTP server or some other collaboration tool where we stored every document
would be helpful. We used many different methods of transferring the
documents instead of just one location. We had to search through all of the
different places in order to keep track of all of the documentation.
51
Problem Report
Time filed:
Date filed (MM/DD/YYYY):
Name of support person taking the report:
E-mail address of support person:
Telephone number of support person:
Name of person filing report:
E-mail address of person filing report:
Telephone number of person filing report:
1. Issue Background
Issue Type:
Request for Info [ ]
Procedural Problem [ ]
Issue Description:
Potential Impact (if not resolved):
Attachments (if any):
No [ ]
Date Resolution Needed: (MM/DD/YYYY)
System Problem [ ]
Other [ ]
Yes [ ]
2. Analysis
Reviewer Name:
Review Completion: (MM/DD/YYYY)
Reviewer Comments:
Initial Recommendation:
Cost/Schedule Impact Analysis Required?
Proposed Assignee:
No [ ]
Yes [ ]
3. Recommendation
Final Recommendation and Comments:
Name
Title
Signature
Date
52
Time Cards
Timecard
Activity Description
ERD
DFD
Physical Process Model
Physical Data Model
Hardware and Software
Specifications
Migration Plans
Training Plans
Program Adjustments
Total Time Spent for the
time period
Ind./Tea
m
Whitney
Whitney
Whitney
Whitney
Whitney
Date
Time Spent
9/22/2013
9/22/2013
10/23/2013
10/23/2013
10/23/2013
120 minutes
120 minutes
35 minutes
35 minutes
15 minutes
Whitney
Whitney
Whitney
11/23/2013
11/23/2013
11/30/2013
20 minutes
20 minutes
4 hours 10
minutes
10 hour 15 minutes
Timecard For: Whitney Capone
Team Name: Team 1
Dates: 12/01/2013
I verify by my signature that the above information is honest and valid:
Signature: Whitney Kathleen Capone
Date: 12/01/2013
53
Time Cards
Timecard
Activity Description
Requirements Definition
Team Leader – Overall
Management
Interface Design
Coding
Total Time Spent for the
time period
Ind./Tea
m
James
James
James
James
Date
Time Spent
9/22/2013
9/23/2013
1.5 hours
4 hours
10/23/2013
4 hours
11/29/2013
12 hours
21 hours 30 minutes
Timecard For: James McCoy
Team Name: Team 1
Dates: 12/01/2013
I verify by my signature that the above information is honest and valid:
Signature: James Michael McCoy
Date: 12/01/2013
54
Time Cards
Timecard
Activity Description
Process Model
Data Model
Use Cases
CRUD Matrix
Put Documents Together
System Conversion
Strategy
System Testing
Total Time Spent for the
time period
Ind./Tea
m
Kimberly
Kimberly
Kimberly
Kimberly
Kimberly
Kimberly
Kimberly
Date
Time Spent
9/24/2013
9/24/2013
9/25/2013
10/23/2013
10/23/2013
12/01/2013
20 minutes
30 minutes
60 minutes
45 minutes
90 minutes
90 minutes
12/01/2013
120 minutes
7 hours 35 minutes
Timecard For: Kimberly Palmer
Team Name: Team 1
Dates: 12/01/2013
I verify by my signature that the above information is honest and valid:
Signature: Kimberly Ann Palmer
Date: 12/01/2013
Timecard
55
Time Cards
Activity Description
Cover Page
Table of Contents
Executive Summary
Work Plan
System Request
Feasibility Analysis
Work Plan Update
Alternative Matrix
Architecture Design
Access Interface Design
Acquisition Strategy
Data Storage Design
Test Plans
Problem Report
Planning Assessment
Migration Plans
Change Management Plans
Putting together all
documentation as team
leader
Program Enhancements
Total Time Spent for the
time period
Ind./Tea
m
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Miranda
Date
Time Spent
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
9/22/2013
10/22/2013
10/22/2013
10/23/2013
10/23/2013
10/23/2013
10/22/2013
11/23/2013
11/23/2013
11/23/2013
11/23/2013
11/23/2013
11/23/2013
5 minutes
5 minutes
30 minutes
45 minutes
30 minutes
60 minutes
15 minutes
25 minutes
10 minutes
65 minutes
60 minutes
35 minutes
120 minutes
20 minutes
20 minutes
10 minutes
10 minutes
45 minutes
12/01/2013
3 hours
13 hours 10 minutes
Timecard For: Miranda Palmisano
Team Name: Team 1
Dates: 12/01/2013
I verify by my signature that the above information is honest and valid:
Signature: Miranda Leigh Palmisano
Date: 12/01/2013
56