COP4331_Fall17_ProjectDeliverables1_Group3
pdf
keyboard_arrow_up
School
University of Central Florida *
*We aren’t endorsed by this school
Course
4331
Subject
Information Systems
Date
Dec 6, 2023
Type
Pages
8
Uploaded by LieutenantMongoose3856
Concept of Operations
Project 2: Bus Tracker
COP 4331, Fall, 2017
Team Name: Group 3
Team Members:
●
Shekh Arefen
●
Brandon Barkes
●
Zhan Kuang
●
Zachary Muller
●
Santiago Perez Arrubla
●
Alberto Young
Contents of this Document
The Current System
The Proposed System
●
Motivation
●
Users and Modes of Operation
●
Operational Scenarios
●
Operational Features
●
Analysis
The Current System
Orlando Transit Tracker is an Android application that tracks the Orlando Lynx bus lines. The
application allows the user to view the schedule for each individual bus line and tracks buses in
real time according to the schedule. The application also allows the user to “subscribe” to their
personal bus route in order to filter to the route(s) that they care about.
The mobile Lynx bus app already has a system much like this. The app has functionality that
allows you to choose a certain bus route and it visually shows you where all the buses on that
route are currently in real time. The existing system also tells you when the next bus will be
arriving to your bus stop.
The Proposed System: Motivation
There will be two main difference between our new system and the current system. First, there
will be two different levels of access, user and administrator. Administrators will be able to see
all the routes while users will only be able to see the route(s) that they “subscribe” to. Second,
This app will have a lot less functionality than the Lynx bus app because it’s only five different
bus routes as opposed to many more that the Lynx app has.
The Proposed System: Users and Modes of Operation
There will be two different classes of user: user and admin. A user with Admin access will be
able to see all five routes while a normal user will only be able to see the routes that they
subscribe to. There will only be a free version of the app because there doesn’t seem to be any
use in putting premium content in a simple bus tracker. There will be three different modes of
operation; account creation, admin mode, and user mode. If you don’t have an account you will
be directed to a new screen that will prompt you to create one (account creation). If you already
have an account you will log in and from there be able to see your personal bus route(s) through
user mode. Through admin mode, Admins will be able to view all lines/bus routes.
The Proposed System: Operational Scenarios
Users will almost exclusively use our app to plan routes to travel around Orlando. Some users
will only need to take one bus to arrive at their destination, in which case their route is very
straightforward. However, many users will have the option to take a few buses to arrive at their
destination, in which case they can use the app to focus on a select few routes in order to more
easily plan their route.
Should the app lose Internet connection, the majority of the app’s functionality would be lost as
the app relies on Google Maps’ API. The user could still have access to the list view of the bus
schedule, however they will not be able to receive any updates to the schedule. Given the
nature of the app, we expect it to most rely on mobile data.
The Proposed System: Operational Features
Must Have:
●
A map detailing the locations of where the buses should be in real time based on their
schedules.
●
Estimated arrival times and locations on the map.
●
The ability to focus on only one bus route at a time, for simplicity’s sake.
●
A list view of the bus schedule.
Would Like to Have:
●
Phone alerts updating the user with information about their chosen bus route.
The Proposed System: Analysis
The bus tracking system will be developed through the Android Studio environment and run on
Android 6.0 Marshmallow. We will use Java to develop the application. Our group does not have
experience programming for Android.Therefore, there will be 1-2 week learning period at the
beginning of development. Since our application will make use of the Google Maps API, an
internet connection will be required. In addition, our application cannot be used outside of
Orlando. An android smartphone or tablet is required to run the app.
Disadvantages:
Our system may rely on manual data input for the schedules. Therefore, in the case a schedule
changes temporarily or permanently and we are not aware of it, our app may not function as
intended. One alternative would be to use an interface that would allows us to track the buses in
real time rather than having to simulate bus locations, but one may not be available.
One major disadvantage of the platform is that it’s being developed in Android studio, so there
will be no iOS version for iPhone users. The tradeoff here is that we all are familiar with Java
which Android is programmed in, as opposed to Swift that most things in the Apple realm are
developed in.
Another limitation is that the app must be connected to the internet to work. If the app is
disconnected, then it can’t hit the API to display the location data. The tradeoff is up-to-date
data on arrival/departure times of buses and accurate display of their location on the map.
One final limitation is the location in which you can use the app. This app is not an all in one
solution for bus routes, it’s for Lynx buses only so you’re limited to using it in Orlando. The
tradeoff is that only Orlando residents will be using it so it will be 100% effective for that use
case.
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
Project Management Plan
Project 2: Bus Tracker
COP 4331, Fall, 2017
Team Name: Group 3
Team Members:
●
Shekh Arefen
●
Brandon Barkes
●
Zhan Kuang
●
Zachary Muller
●
Santiago Perez Arrubla
●
Alberto Young
Contents of this Document
Project Overview
Applicable Standards
Project Team Organization
Deliverables
Software Life Cycle Process
Tools and Computing Environment
Configuration Management
Quality Assurance
Risk Management
Table of Work Packages, Time Estimates, and Assignments
GANNT Chart
Technical Progress Metrics
Plan for tracking, control, and reporting of progress
Project Overview
We are creating a mobile app that allows the user to track bus route departure and arrival times,
as well as visualize the routes as the buses move through them. The application will cover 5
different bus lines and their routes.
Applicable Standards
●
Coding Standard
File Organization - Every source file will begin with header comments for author,
description, etc. Right underneath that will be all the package inclusion statements to
import all the libraries we need.
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855
.html#11684
Indentation - Avoid lines longer than 80 characters, for line breaking and wrapping do it
after commas, before operators, and make sure all lines are aligned.
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091
.html#313
Comments - Comments will be made above the line of code you are leaving a comment
about and using the standard “//” to indicate a comment
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141999
.html#216
Naming Conventions - standard naming conventions will be used as specified here
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-135099
.html#367
●
Artifact Size Metric Standard
Artifacts in order of Descending size are as follows:
Database
- There will be a database to hold user login info
Source Files
- There will be a number of source files that include the necessary
classes,user interface data, graphics, and interaction logic.
API
- We’ll need an API to take GPS coordinates as the buses move through their routes
and display them visually on a map.
●
Metrics - There will be five different stages of deliverables spaced out every 2 weeks
throughout the semester.
Project Team Organization
●
Roles
Project Manager - Zach Muller
Backend - Zach Muller, Zhan Kuang
Frontend - Alberto Young, Brandon Barkes, Santiago Perez Arrubla, Shekh Arefen
●
Communication
- handled through Discord
Deliverables
Artifact
Due Dates
Individual Weekly Progress Reports
Weekly (Fridays) submission throughout the
semester through Discord #reports channel
Concept of Operations
September 25, 2017
Software Project Management Plan
(SPMP)
September 25, 2017
Software Requirements Specification
(SRS)
October 9, 2017
Test Plan
November 15, 2017
High-Level Design
October 23, 2017
Detailed Design
October 23, 2017
Test Plan
November 15, 2017
Test Results
December 1, 2017
Source, Executable, Build Instructions
December 1, 2017
Software Life Cycle Process
We’re using the Spiral Model for software lifecycle because the other models are too simplistic
or more suited for continual release and maintenance. The spiral model has four stages: Plan,
Determine goals, alternatives, and constraints, Evaluate alternatives and risks, Develop and
Test. We can keep doing these four steps over and over as we design and implement our app,
for there will be many different prototypes along the way.
Tools and Computing Environment
●
Compiler: Gradle ( Android Studio )
●
Programming Language(s): Java
●
Environment: Android Studio
●
Operating System: Android 6.0 Marshmallow
●
Interface(s): Google Maps API
●
Tools: Android AVD Manager, Android SDK Manager, Notepad++, Git
Configuration Management
Everyone will keep a local remote repository, and commit changes with sufficient comments so
that we know what changes were made. The project manager is responsible for approving the
commits and making sure the documentation for each is sound and sufficient. Once the commit
is approved, the committer will then push the changes to the repo.
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
- Access to all documents
- Unlimited textbook solutions
- 24/7 expert homework help
Quality Assurance
Each week a different group member will be a quality assurance tester. They’re responsible for
testing the currently implemented functionality and essentially trying to break it. This will allow
us to find bugs in the software faster and fix them so that the end user has the best product
possible. The results will be reported in a separate channel on our Discord server.
Risk Management
It is expected that as a result of hurricane Irma and our training period at the beginning of
development, late stage features beyond the scope of the base application may not be
implemented.
The app may not function as intended if the bus line schedules change unexpectedly since the
application may rely on manually input bus schedule data.
Table of Work Packages, Time Estimates, and Assignments
Note:
Estimated completion times are approximate summations of time working on the project
over the course of the semester; for example, Database deployment won’t take 2-4 days
straight, but a total of 2-4 days after the learning process and actually doing it.
Back-end
Database Deployment
- Zach; 2-4 days
Initial Database Data Input
- Zhan; 2-4 days
Database interaction logic
- Zach, Zhan; 1 week
Front-end
UI
- Brandon, Alberto, Shekh; 1-2 weeks
UX Interaction Logic
- Brandon, Alberto; Shekh 1-2 weeks
Class Development
- Alberto, Santiago 2-4 days
Technical Progress Metrics
Requirements Phase
- total number of requirements, number of requirement changes.
System Design Phase
- number of system components to integrate, time it takes to set up each
system component, each components memory usage and speed, speed and memory usage of
system as a whole.
Program Design Phase
- Number of classes, number of methods, execution time of methods,
lines of code per file, file sizes.
Coding
- Time it takes to write the program, time to debug and test, effective and readable
comments.
Unit and Integration Testing -
Number of pieces to put together, time it takes to put the pieces
together, time it takes to troubleshoot the unit composition.
System Testing -
Number of test cases for the system, time it takes to run all the test cases,
latency of system interacting with web components, debugging time
Acceptance Testing -
Number of people using the system, people who like the system vs.
people who don’t, Number of suggested changes to the system. Time it takes for users to grasp
the system and use it as intended.
Operation and Maintenance
- Theoretical cost to deploy system, Number of people it takes to
maintain system, How often maintenance needs to be done on the system.
Plan for tracking, control, and reporting of progress
Each week, each team member collectively read and analyze the logs; examine the technical
content of the work done to date; examine the technical progress metrics; consider the QA
results; reassess the potential project risks; and take corrective action if necessary.
We have a reports text channel on our Discord server where each group member will post a
weekly update on what they’re currently working on. This can extend do daily updates as well as
team members finish their respective projects. If a team member seems to not be completing
their tasks in a timely manner then the project manager can confer with the other team
members about the situation. If they agree then the project manager can talk to the team
member who is falling behind to see how they can help get the team member up to speed. The
same goes for quality of work completed.