CS355, Section 1, Spring 2020
Team Project – Scrum, Sprint 1
Travel Agent: Agent, Server, Display
Due: Friday, April 24th at 5PM
(your GitLab repos will be cloned for evaluation shortly after this date/time)
Overall Project
The team project for this semester will be a travel agent system. Imagine you own a company
that arranges vacation packages. You hire travel agents to take calls and book trips for clients.
The travel agents have an interface to do their work. Imagine the agents work in a room like
P115. You may recall there are video screens on the walls in P115. These video screens are a
good place to show a display of agents currently working, recommended trips, and low
availability trips. Finally, there is a supervisor, or administrator, responsible for starting the call
center each morning.
Process
We will use a Scrum-like process for working on this project. Scrum divides work into sprints
(for us, two-week work periods), with the following structure:
- Initial planning meeting - at the beginning of the sprint, including the topics of:
o Discuss the project to ensure overall understanding
o Generate a list of tasks (based on the project description), try to make
your tasks fairly small (15 minutes to several hours) if possible
A task like “make client software” is too large and broad; divide this
up into “get client/server socket communication working”, “identify
agent through workstation name”, “do not allow second agent
from same workstation to connect to server”, etc.
o Estimate the work times for each task
o Prioritize your task list, with the tasks that must be done earlier and/or are
more important given higher priority. No priority number should be used
more than once.
o Divide the sprint tasks among the team members
- Regular work - each day, try to do some quality work, accomplish part or all of at
least one task
- Regular status meetings (the “Scrum”) - preferably each day, no less than every
other day), focusing on three topics:
o What have you done since the last status meeting?
o What do you plan to do before the next status meeting?
o What obstacles/problems/issues have you encountered in your recent work
that are interfering with your progress?
- Retrospective meeting – at end of each sprint, reflect on what worked in this sprint,
what didn’t work well in this sprint, how to improve your process for the next
sprint.
See the Scrum notes on Canvas for more information on the Scrum process in general.
Each team must use GitLab to store your team code. The only code I’ll evaluate (at the end of
each sprint) will be what is in your GitLab repository on the UWEC server.
I also want each team to use the GitKraken Glo Boards to set up tasks for your project and track
task progress and completion that way. One member of each team should create a board for
the Travel Agent project, add the other member and myself to the board (gurunghl), and use
this board regularly. More information on Glo Boards will be posted later in the week of April
13th.
Sprint Tasks
The overall tasks for this sprint are to develop the server (including agent handler), agent,
and display subsystems using Java sockets. Several additional requirements will be added to
the overall project description, and are listed here:
- The agent view and display view must be GUI-based. You are allowed to use any
standard Java GUI library from the following list: AWT, Swing, SWT, JavaFX. No
additional GUI (or other libraries, besides ojdbc8.jar for Oracle connectivity) may be
used without instructor/client permission.
- The agent view should include information identifying what it is (e.g. Travel
Agent System - Agent, and should include at least three buttons as follows:
o Find Trips button, with primary color of green in the button text,
background fill, or outline
o List Customers button, with primary color of red in the button text,
background fill, or outline
o Purchase Trip, after a number of tickets to purchase has been selected
o A small display area for status or error messages returned by the server (e.g.
if there are not enough seats available on a trip, a purchase cannot be made
and a message should be printed notifying the agent of this).
- The agent subsystem should only be allowed to connect to the server once for
each workstation; any subsequent requests from the same workstation should be
disallowed on startup.
- The display should update every 3-5 seconds.
- The display view should include:
o General
Text identifying the application (e.g. Travel Agent Display)
the room (Phillips 115 Lab)
the current time
o For each agent, two columns should be used (and labeled)
Agent name (start at 1, go down as far as needed)
The workstation name making the request (in P115, this is in the form
LAB-P115-xy, where xy is currently a number between 01 and 24, but
we want to support 100 machines (that is, numbers between 01 and
99)
o For each trip, four columns should be used (and labeled)
Trip name
Trip destinations
Maximum trip capacity
Current available seats
o The five lowest and five highest availability trips should be shown
Highest availability should be labeled ‘Recommended’
Lowest availability should be labeled ‘Almost Gone’
o The general style of the display (including colors, font choices, font sizes) is
up to each team, though generally should be readable and professional (do
not choose extreme colors or nonstandard fonts).
o Since we can’t easily control the display, the display window does not have
to be scrollable, but should show at least the top 5 recommended and
‘avoided’ trips.
- Currently, if you stop one of the agent, server, or display subsystem programs, you
may cause an unhandled exception in one or several of the other subsystems,
sometimes with this exception happening within a loop. For the travel agent
system, all exceptions should be handled so that:
o Stopping a single agent, many agents, or all agents does not cause
an unhandled exception in the server or display
o Stopping the display should not cause an unhandled exception in the server
or any agent
o Stopping the server should not cause an unhandled exception in the display
or any agent; for now any result (display and agents stopping, display and
agents still running but given that connection is lost they don’t do
anything) is allowed, and we’ll work on this more in sprint 2.
You may use the chat client/server code posted as a starting point or you may develop
your own code from scratch if you would like to do so (though this is not recommended
unless you are very comfortable with Java sockets.)
• The chat server system is quite similar in architecture to a possible solution to our
travel agent project – the server is already generating client-helper instances to
work with each agent, and has a structure set up to track all agents through that
client’s helper.
• To allow the display system to also communicate with the server, you will need
to adjust the chat client/server code to “share” cycles with agent connections
and the display update, as noted in the overall Project Description.
You may not change the structure of the Travel Agent system to use other architectures, such
as a web server and web client system. Please contact the instructor if you have any questions
on this.