Weeblymirandapalmisano.weebly.com/.../1/4/9/2/14923906/phase3.docx · Web viewTable of Contents....

Problem Report

Tangipahoa Transportation System

Project for Levar James

Team 1 Members:

Whitney Capone

James McCoy

Kimberly Palmer

Hardware and Software Specification

Executive Summary

Miranda Palmisano

ISDS 4125

FALL 2013

10/24/2013

6

3

Executive Summary3

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 Request16

Statement of Work17

Work Plan18

Feasibility Analysis19

Requirements Definition20

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

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-to-navigate design.

Table of Contents

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.

24

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.

Recommended Acquisition Strategy

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

Technical Issues:

Develops desirable in-house skills

15

Little interest in developing in-house skills

1

15

Developed using Access and VB. Little interest in developing in-house skills.

1

15

Developed in VB and Java. No in-house interest in developing skills

1

15

Integration with existing system

15

Easy to pull existing spreadsheets out of excel and into Access

3

45

Easy to integrate information from Excel to VB.

4

60

More difficult to integrate with existing data

2

30

Experience with product

10

Users have a little familiarity with this product.

2

20

Users are not familiar with this product.

2

20

No experience

1

10

Economic Issues:

Cost

25

No initial charge

5

125

No initial charge

5

125

May have a charge

2

50

Organizational Issues:

Demonstrated product in market

15

Program is already in use at their facility

5

75

Program used by other companies as well as IT sector

5

75

Company does not have experience

2

30

Customizable interface

20

Yes – switchboard

4

80

Easy to customize

5

100

Would need experience to customize

4

80

TOTAL

100

360

395

215

Alternative Matrix

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.

Portability

1.5 The system will need to remain current with evolving Web standards and Visual Studio standards.

Maintainability

1.6 No special maintainability requirements anticipated.

2. Performance Requirements

Speed

2.1 Response time must be less than 10 seconds.

Capacity

2.2 There will be a maximum of 10 simultaneous users at peak use times.

Availability and Reliability

2.3 The system should be available 24/7.

2.4 The system shall have 99% uptime performance.

3. Security Requirements

System Value

3.1 Access to the application will be restricted to authenticated users.

Access Control

3.2 Users can access the application with username and password from Active Directory

Encryption/Authentication

3.3 No encryption required

Virus Control

3.4 Downloads must be verified as virus free

4. Cultural and Political Requirements

Multilingual

4.1 No special multilingual requirements anticipated

Customization

4.2 No special customization requirements are anticipated.

Unstated Norms

4.3 No special unstated norm requirements are anticipated.

Legal

4.4 Sensitive information such as birthday, drivers license number, SSN will be secure.

Architecture Design

Design

Architecture Design

26

Client

Server

Operating System

Windows Vista or Higher

Windows Vista or Higher

Special Software

Microsoft Office 2008

Microsoft Visual Studio 2008

Microsoft Access 2008

Hardware

Middle range Windows computer capable of supporting Microsoft Office 2008

Windows Server capable of running Microsoft Access 2008

Network

Broadband or Dial-up

Dual 100 Mbps Ethernet

Hardware and Software Requirements

Interface Structure Design

Interface Design

REQUESTED BY: Miranda PalmisanoDATE: September 25, 2013

ORGANIZATION: Tangipahoa Transportation System

ADDRESS: 59656 Puleston Road Amite, LA 70422

CONTACT: LeVar James – 985-748-2423

TYPE OF SYSTEM:URGENCY:

[X] New System[ ] Immediate – Operations are impaired or opportunity lost

· [ ] System Enhancement[ ] Problems exist, but can be worked around

[ ] System Error Correction [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

System Request

· [ ] Reject for reason: _________________________________________________________________________________________

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.

Statement of Work

Estimated

Actual

Task ID

Task Name

Assigned To

Duration (Hours)

Start Date

Finish Date

Start Date

Finish Date

Duration

(Hours)

Status

1

Planning & Analysis Phase

Open

1.1

Cover Page

Miranda

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.10

Complete

1.2

Table of Contents

Miranda

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.10

Complete

1.3

Executive Summary

Miranda

.75

9/22/2013

9/22/2013

9/23/2013

9/23/2013

.50

Complete

1.4

Work Plan

Miranda

1.0

9/22/2013

9/22/2013

9/22/2013

.75

Complete

1.5

System Request

Miranda

.50

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.50

Complete

1.6

Feasibility Analysis

Miranda

1.5

9/22/2013

9/22/2013

9/22/2013

9/22/2013

1.0

Complete

1.7

Requirements Definition

James

1.0

9/22/2013

9/22/2013

9/22/2013

9/22/2013

1.0

Complete

1.7.1

Functional

James

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.25

Complete

1.7.2

Non-Functional

James

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.25

Complete

1.7.3

As-Is System

James

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.25

Complete

1.7.4

Improvements

James

.25

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.25

Complete

1.8

Use Cases

Kimberly

1

9/22/2013

9/22/2013

9/22/2013

9/22/2013

1

Complete

1.9

Process Models

Kimberly

.5

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.5

Complete

1.10

Data Models

Kimberly

.5

9/22/2013

9/22/2013

9/22/2013

9/22/2013

.5

Complete

1.11

DFD’s

Whitney

1

9/22/2013

9/22/2013

9/22/2013

9/22/2013

1

Complete

1.12

ERD’s

Whitney

1

9/22/2013

9/22/2013

9/22/2013

9/22/2013

1

Complete

2

Design Phase

Complete

2.1

Enter data into Access database

Miranda

.75

10/20/2013

10/20/2013

10/20/2013

10/20/2013

.75

Complete

2.1.1

Create tables

Miranda

.30

10/20/2013

10/20/2013

10/20/2013

10/20/2013

.30

Complete

2.1.1

Create access relationships

Miranda

.15

10/20/2013

10/20/2013

10/20/2013

10/20/2013

.15

Complete

2.2

Create interface in VB

James

3.0

10/20/2013

10/20/2013

10/20/2013

10/20/2013

3.0

Complete

2.3

Alternative Matrix

Miranda

.25

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.25

Complete

2.4

Architecture Design

Miranda

.10

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.10

Complete

2.5

Hardware and Software specifications

Whitney

.50

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.50

Complete

2.6

Physical Process Model

Whitney

1

10/23/2013

10/23/2013

10/23/2013

10/23/2013

1

Complete

2.7

Program Design Specifications

James

.25

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.25

Complete

2.8

Physical Data Model

Whitney

.50

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.50

Complete

2.9

Updated CASE repository

Whitney

.25

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.25

Complete

2.10

CRUD Matrix

Kimberly

.50

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.50

Complete

2.11

Put all documents together

Kimberly

2.0

10/23/2013

10/23/2013

10/23/2013

10/23/2013

2.0

Complete

2.12

Data storage design

Miranda

.50

10/23/2013

10/23/2013

10/23/2013

10/23/2013

.50

Complete

Work Plan


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.


System

Use Cases

Tangipahoa Transportation system

Author (s):__Kimberly Palmer__Date:9-25-13

USE CASE NAME:

Sends Information

PRIMARY BUSINESS ACTOR:

User

OTHER PARTICIPATING ACTORS:

· Bus

· Driver

· Route

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.

PRE-CONDITION:

There is no precondition requirement for inputting data

TRIGGER:

This use case is initiated when an actor submits information to be added to the database.

TYPICAL COURSE

Actor Action

System Response

OF EVENTS:

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:

The use case is concluded when the information is added to the database

POST-CONDITION:

There are no post condition requirements.

BUSINESS RULES

There are no business rules that must be followed to allow for the input of data

IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS

The User will be using an access database and a web form. The other three actors will be using a web form.

ASSUMPTIONS:

Those who are inputting the data are doing it correctly and have the correct credentials

OPEN ISSUES:

None

Tangipahoa Transportation system

Author (s):__Kimberly Palmer__Date:9-25-13

USE CASE NAME:

Requests Information

PRIMARY BUSINESS ACTOR:

User

OTHER PARTICIPATING ACTORS:

None

DESCRIPTION:

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

PRE-CONDITION:

The request must be made within the rules for queries or reports

TRIGGER:

This use case is initiated when an actor submits a request for information from the database.

TYPICAL COURSE

Actor Action

System Response

OF EVENTS:

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:

The use case is concluded when the user receives the information

POST-CONDITION:

There are no post condition requirements

BUSINESS RULES

There are no business rules that must be followed to allow for the requesting of data

IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS

The User will be using an access database or a web form to request the information as well as to view the information requested

ASSUMPTIONS:

Those who are requesting the data are doing it correctly and have the correct credentials

OPEN ISSUES:

None

Use Cases

Hardware and Software Specification

Use Cases

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

System opens Accident Report page

Driver Information button

System opens Driver page

Bus Information Button

System opens Bus page

Maintenance Button

System opens Maintenance page

Requirement Button

System opens Requirement page

Input Name

Type

Used By

Notes

N/A

N/A

N/A

N/A

Output Name

Type

Used By

Notes

N/A

N/A

N/A

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


Name: Accident Report

Purpose: Allows user to submit necessary information for an accident report



Code: Visual Basic

Event

Output

Add Button Clicked

System creates blank Driver Information form

Delete Button Clicked

System deletes current Driver Information displayed

Save Button Clicked

System saves current Driver Information displayed

Submit Button Clicked


Exit Button Clicked

System closes program

Tangipahoa Parish Picture Button Clicked

System opens Menu page

Input Name

Type

Used By

Notes

txtAccidentID

String(25)

System User

Accident ID Number

txtAccidentDesc

String (25)

System User

Description of Accident

txtBusTagID

String(25)

System User

Bug Tag ID Number

dateAccidentDate

DateTime

System User

Date of Accident

dateDateReviewed

DateTime

System User

Date Accident was Reviewed

txtPoliceComplaintNum

String(25)

System User

Police Complaint Number

txtTotalStudentsInj

String(25)

System User

Total Number of Students Injured

cmbDriverID

ComboBox

System User

Driver ID Number

txtDriverLName

String(25)

System User

Driver Last Name

txtDriverFName

String(25)

System User

Driver First Name

dateHireDate

DateTime

System User

Driver Hire Date

cbDriverStatements

CheckBox

System User

Driver Statements Completed (Yes/No)

cbTrinity

CheckBox

System User

Accident Report Sent to Trinity (Yes/No)

cbPreventable

CheckBox

System User

Accident Preventable(Yes/No)

cbTotalVeh

Checkbox

System User

Total W/ Other Vehicles(Yes/No)

cbFixedObject

Checkbox

System User

Fixed Object Hit (Yes/No)

cbPropertyOnly

Checkbox

System User

Property Only (Yes/No)

Output Name

Type

Used By

Notes

Accident_Report

DataGrid

System User

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


IF Exit Button clicked

Then program closes

IF Tangipahoa Parish Picture Button clicked

Then Menu page opens



51

Name: Driver

Purpose: Allows user to add new driver information, edit driver information, and view driver information



Code: Visual Basic

Event

Output

Add Button Clicked

System creates blank Driver Information form


System deletes current Driver Information displayed

Save Button Clicked




Exit Button Clicked




Input Name

Type

Used By

Notes

cmbDriverID

String(25)

System User

Allows user to select Driver ID

txtLastName

String (25)

System User

Driver Last Name

txtFirstName

String(25)

System User

Driver First Name

dateHireDate

DateTime

System User

Driver Hire Date

txtPhoneNumber

String(10)

System User

Driver Phone Number

cmbClassification

String(25)

System User

Driver Classification

Output Name

Type

Used By

Notes

Driver_Report

DataGrid

System User

Shows the Driver Information Spreadsheet

Pseudocode:


Then open blank Driver form


Then Delete Driver displays






Then program closes




Name: Maintenance




Code: Visual Basic

Event

Output

Add Button Clicked

System creates blank Maintenance form


System deletes current Maintenance displayed

Save Button Clicked

System saves current Maintenance displayed


System saves current Maintenance displayed

Exit Button Clicked




Input Name

Type

Used By

Notes

txtTagID

String(25)

System User

Bus Tag ID

txtReportNum

String (25)

System User

Report Number

txtTypeNum

String(25)

System User

Type of maintenance

txtTypeDes

String(25)

System User

Description of maintenance

Output Name

Type

Used By

Notes

Maintenance_Report

DataGrid

System User

Shows the Maintenance Spreadsheet

Pseudocode:


Then open blank Maintenance form


Then Delete Maintenance displays


Then current Maintenance saves


Then current Maintenance saves


Then program closes




Name: Requirements




Code: Visual Basic

Event

Output

Add Button Clicked

System creates blank Requirements form


System deletes Requirements displayed

Save Button Clicked

System saves current Requirements displayed


System saves current Requirements displayed

Exit Button Clicked




Input Name

Type

Used By

Notes

txtRequirementNum

String(25)

System User

Requirement Number

txtDesc

String (25)

System User

Description of Requirement

txtFormID

String(25)

System User

Form ID

txtDriverID

String(25)

System User

Driver ID

Output Name

Type

Used By

Notes

Requirements _Report

DataGrid

System User

Shows the Requirements Spreadsheet

Pseudocode:


Then open blank requirements form


Then Delete requirements displays


Then current requirement saves


Then current requirement saves


Then program closes





Physical Data Model

CRUD Matrix

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

Approximate Number of Rows in DB

Employee Information

Simple (text and numbers)

Transaction Processing

Relational DBMS

1000 rows

Bus Information



Relational DBMS

1000 rows

Accident Information



Relational DBMS

100 rows

Maintenance Information



Relational DBMS

500 rows

Requirements Information



Relational DBMS

100 rows

Storage Design

Time Cards

Time Cards

Preparing the Business

Preparing the Technology

Preparing the People

Conversion Strategy: Direct Conversion, Simultaneous and Whole system

Install software

Revise management policies

Prepare a business contingency plan

Convert data

Assess costs and benefits

Motivate adoption

Conduct training

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 whole-system 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.

Migration Plan

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.

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.

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 whole-system 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

System Conversion Strategy

Test Stage

Web Interface

System Management

System Interfaces

Unit tests

Black-box tests

Black-box tests

Black-box tests

Integration tests

User interface tests; use scenario tests

User interface tests; use scenario tests

System interface tests

System tests

Requirements tests; usability tests

Requirements tests;

Requirements tests;

Acceptance tests

Alpha test; beta test



Test Plan

Program ID: Menu FormVersion number: 1

Tester: Miranda PalmisanoDate designed: 11/20/2013 Date conducted: 11/29/2013

Results: Passed☐ Open Items:

Test ID: 1Requirement addressed: Main Menu

Objective:

Make sure all of the buttons on the main menu open the appropriate forms.

Test cases

Interface ID

Data Field

Value Entered

1. Accident Report

Button

Clicked Button

2. Driver Information

Button

Clicked Button

3. Bus Information

Button

Clicked Button

4. Maintenance

Button

Clicked Button

5. Requirements

Button

Clicked Button

6. Driver Scorecard

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.

Test Plan

Program ID: Accident Report FormVersion number: 1


Results:☐ Passed☐ Open Items: Fix the Integer problem that is occurring when clicking the submit button.

Test ID: 2Requirement 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

Data Field

Value Entered

1. Accident ID

Text box

1

2. Accident description

Text box

Test

3. Bus Tag ID

Text box

1

4. Accident Date

Date

Saturday November 30, 2013

5. Police Complaint #

Text box

1

6. Total Students Injured

Text box

1

7. Total Non- Students Injured

Text box

1

8. Driver ID

Text box

1

9. Main Menu

Button

Clicked

10. Submit

Button

Clicked

6. Exit

Button

Clicked


-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.


-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.

Test Plan

Program ID: Bus Information FormVersion number: 1


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: 3Requirement 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

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Bus Tag ID

Label

Auto

5. Bus Make

Text Box

TEST

6. Driver ID

Text Box

3

Script







-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.

Program ID: Bus Information FormVersion number: 2


Results:Passed☐ Open Items:

Test ID: 4Requirement addressed: Bus Information Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Bus Tag ID

Label

Auto

5. Bus Make

Text Box

TEST

6. Driver ID

Text Box

3

Script







-The Bus Tag ID and Driver ID are working properly.

-The Bus Make is now working correctly.


Program ID: Driver Information FormVersion number: 1


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: 5Requirement addressed: Driver Information Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Driver Last Name

Text Box

Palmisano

5. Driver First Name

Text Box

Miranda

6. Driver ID

Label

Auto

7. Hire Date

Date

November 18, 2013

8. Phone Number

Text Box

9857058835

9. Classification

Text Box

TEST







-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.


Program ID: Driver Information FormVersion number: 2


Results:Passed☐Open Items:

Test ID: 6Requirement addressed: Driver Information Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Driver Last Name

Text Box

Palmisano

5. Driver First Name

Text Box

Miranda

6. Driver ID

Label

Auto

7. Hire Date

Date

November 18, 2013

8. Phone Number

Text Box

9857058835

9. Classification

Text Box

TEST







-The Driver ID is working properly.

-After entering information and clicking submit, everything is entered correctly to the table/database.


Program ID: Maintenance FormVersion number: 1



Test ID: 7Requirement addressed: Maintenance Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Tag ID

Label

1

5. Maintenance ID

Text Box

1

6. Report Num

Text Box

1

7. Type Num

Text Box

1

Script





-All of the text boxes should allow for data to be entered and saved in the table below.


-All text boxes are working properly and are allowing info to be saved to the database.


Program ID: Requirements FormVersion number: 1



Test ID: 8Requirement addressed: Requirements Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Form ID

Label

Auto

5. Driver ID

Text Box

1

6. Requirements Num

Text Box

1

7. Requirements Desc

Text Box

test

Script









Program ID: Scorecard FormVersion number: 1



Test ID: 9Requirement addressed: Scorecard Form

Objective:


Test cases

Interface ID

Data Field

Value Entered

1. Menu

Button

Clicked Button

2. Submit

Button

Clicked Button

3. Exit

Button

Clicked Button

4. Scorecard ID

Label

Auto

5. School

Text Box

LSU

6. Bus ID

Text Box

1

7. Last Name

Text Box

Palmisano

8. First Name

Text Box

Miranda

9. Physical

Checkbox

Checked

10. Physical

Date

November 18, 2013









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.

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.

Project Assessment

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.

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 [ ]

System Problem [ ]

Other [ ]

Issue Description:

Potential Impact (if not resolved):

Attachments (if any):

No [ ]

Yes [ ]

Date Resolution Needed: (MM/DD/YYYY)

2. Analysis

Reviewer Name:

Review Completion: (MM/DD/YYYY)

Reviewer Comments:

Initial Recommendation:

Cost/Schedule Impact Analysis Required?

No [ ]

Yes [ ]

Proposed Assignee:

3. Recommendation

Final Recommendation and Comments:

Name

Title

Signature

Date

Timecard

Timecard For: Whitney Capone

Team Name: Team 1Dates: 12/01/2013

Activity Description

Ind./Team

Date

Time Spent

ERD

Whitney

9/22/2013

120 minutes

DFD

Whitney

9/22/2013

120 minutes


Whitney

10/23/2013

35 minutes

Physical Data Model

Whitney

10/23/2013

35 minutes

Hardware and Software Specifications

Whitney

10/23/2013

15 minutes

Migration Plans

Whitney

11/23/2013

20 minutes

Training Plans

Whitney

11/23/2013

20 minutes

Program Adjustments

Whitney

11/30/2013

4 hours 10 minutes

Total Time Spent for the time period

10 hour 15 minutes

I verify by my signature that the above information is honest and valid:

Signature: Whitney Kathleen Capone

Date: 12/01/2013

Timecard

Timecard For: James McCoy



Ind./Team

Date

Time Spent


James

9/22/2013

1.5 hours

Team Leader – Overall Management

James

9/23/2013

4 hours

Interface Design

James

10/23/2013

4 hours

Coding

James

11/29/2013

12 hours


21 hours 30 minutes


Signature: James Michael McCoy

Date: 12/01/2013

Timecard

Timecard For: Kimberly Palmer



Ind./Team

Date

Time Spent

Process Model

Kimberly

9/24/2013

20 minutes

Data Model

Kimberly

9/24/2013

30 minutes

Use Cases

Kimberly

9/25/2013

60 minutes

CRUD Matrix

Kimberly

10/23/2013

45 minutes

Put Documents Together

Kimberly

10/23/2013

90 minutes

System Conversion Strategy

Kimberly

12/01/2013

90 minutes

System Testing

Kimberly

12/01/2013

120 minutes


7 hours 35 minutes


Signature: Kimberly Ann Palmer

Date: 12/01/2013

Timecard

Timecard For: Miranda Palmisano



Ind./Team

Date

Time Spent

Cover Page

Miranda

9/22/2013

5 minutes

Table of Contents

Miranda

9/22/2013

5 minutes

Executive Summary

Miranda

9/22/2013

30 minutes

Work Plan

Miranda

9/22/2013

45 minutes

System Request

Miranda

9/22/2013

30 minutes


Miranda

9/22/2013

60 minutes

Work Plan Update

Miranda

10/22/2013

15 minutes

Alternative Matrix

Miranda

10/22/2013

25 minutes

Architecture Design

Miranda

10/23/2013

10 minutes

Access Interface Design

Miranda

10/23/2013

65 minutes

Acquisition Strategy

Miranda

10/23/2013

60 minutes

Data Storage Design

Miranda

10/22/2013

35 minutes

Test Plans

Miranda

11/23/2013

120 minutes

Problem Report

Miranda

11/23/2013

20 minutes

Planning Assessment

Miranda

11/23/2013

20 minutes

Migration Plans

Miranda

11/23/2013

10 minutes

Change Management Plans

Miranda

11/23/2013

10 minutes

Putting together all documentation as team leader

Miranda

11/23/2013

45 minutes

Program Enhancements

Miranda

12/01/2013

3 hours


13 hours 10 minutes


Signature: Miranda Leigh Palmisano

Date: 12/01/2013

0

Main Menu

1.1

2

Driver Information

1.1.2

3

Bus Information

1.1.3

4

Maintenance

1.1.4

5

Requirement

1.1.5

1

Accident Report

1.1.1

Weeblymirandapalmisano.weebly.com/.../1/4/9/2/14923906/phase3.docx · Web viewTable of Contents....

Documents

Transcript of Weeblymirandapalmisano.weebly.com/.../1/4/9/2/14923906/phase3.docx · Web viewTable of Contents....