1

Faiga Revah
CST 438- Software Engineering
August 8, 2017
Team++ Software Engineering J2EE Project

1. Introduction and background:

The team project is a word scramble game. The interface of the game provides the player with a
scrambled word. The player has to input the unscrambled word. If the player has guessed
correctly, s/he is given another word. If the player has guessed incorrectly, the same word
appears. The player has 10 incorrect guesses before the game terminates and the player loses.
In order to win, the player must guess 5 words correctly. Once the player has guessed won the
game, they can receive their score. The score is based on the time it took to play and is
calculated using the logarithm of the time. (When the game begins, the timer is started.) If the
player has scored in the top ten of all players, his/her score is prompted for his/her initials, and
the score and initials are inputted into the high scores chart. The player can then begin the
game again.
The game itself is not complex. It has a simple set of rules and basic-to-intermediate
functionality. The goal of the project was not to create a complex Java program with multiple
threads, interfaces and databases, since we had already done that in our software design class.
Rather, we create a problem that was simple in its functionality so that the team could focus on
mastering J2EE and the Agile process. We wanted a project that would provide enough work for
four people per iteration, but not too much work that we were focused on details instead of the
process as a whole. We chose this project in particular because it required us to implement a
little bit of everything- Java, JavaScript, HTML, SQL, JDBC and JPA. The game also lent itself
to iterative development, in that we began with basic functionality and were able to add new
requirements each week.

2. Agile Techniques
Our team used the Agile process to develop the game. At least once a week, we would have a
weekly meeting, where we would discuss the past weeks work, and plan out requirements for
the next week. We would also use that time to walk through our code, review each others code,
and help any team members out who were stuck. The development process was iterative; we
began with a few requirements, and as each functionality was completed, we would build more
functionality on top of that. We used Pivotal Tracker to track the requirements and progress of
the code. When each team member completed their requirement, they would notify the team
using Pivotal tracker. The scrum master for that week (we rotated on a bi-weekly basis) would
then have to review and accept the updates.
We also used some of our team meeting time to do pair programming, where one team member
would share their screen, and together with another member, talk through the programming
process while programming. This was incredibly helpful in this project, considering that it
required so many different knowledge bases (such as SQL, JavaScript, Java, etc.) and if one
team member was more familiar with a concept, they could help the process along during pair
programming. For example, we wanted to create a timer in our game. Based on the way the
 2

game is structured, JavaScript was the best way to implement the timer. I had little experience
with JavaScript, so I suggested that we create the timer using the Java timer library, and then
push that value through the servlet to the jsp page, updating it every second. Ryan, however,
was more familiar with JavaScript, and suggested that we create the timer using JavaScript. The
pair programming process was instrumental in our team using the tools optimally.
Each team member would commit their changes to GitHub, and usually once the changes were
reviewed, the team member would push the code to GitHub. Although GitHub did present some
challenges at times, it was ultimately helpful.
Our project benefitted tremendously from the Agile process. Had we created the project in a
Waterfall process, we would have only had some basic functionality, and it would have been far
more error prone. As mentioned above, pair programming was instrumental in us being able to
complete the project better, with fewer errors and more efficient design patterns. The iterative
process was also important, since we did not have time to sit and plan out our requirements
from start to finish. Since we are at a mostly beginner level, we wanted the flexibility to be able
to feel out J2EE at first, test our skill level, and then move forward. We could not have
developed in the Waterfall process, since our skill levels were questionable and unreliable in the
beginning. Agile allowed for us to develop increasingly complex functionality as we proceeded,
but also prevented us from getting stuck with impossible-to-fulfill requirements. Agile also
helped us catch errors during code reviews, where sometimes apparent errors that were missed
by one teammate were caught immediately by another.
Our team maintained communication through email and Hangouts chat during the week. Our
meetings would take place on Google Hangouts as well. Communication was consistent and
fluid, and was only interrupted when team members were unable to access a device (such as
being on a plane or out of the country.) Overall, we had effective communication, with every
team member showing up for meetings, and communicating with the team every time
necessary.
On my next project, I would be beginning with a higher level skill set and I have a much better
understand of how to optimize the Agile process. Firstly, our development was not test-driven
for the most part. We were more concerned with getting the program to work, and did not spend
the time writing tests before hand. Fortunately, since the program was not so complex, we were
able to retroactively create test cases and were not hindered by any egregious errors. However,
I have learned how important it is to develop with TDD, and I will make sure that it is the
emphasis of my next project.
Our team velocity, the average points per iteration, is 9. On average, our team completed 4
requirements- one for each team member. Thus, 5 large requirements cannot be completed in
one iteration, since that would be between 12-15 points. Although we did once complete 12
points in an iteration, it would be unwise to assign five large requirements in one week. It would
likely take an iteration and a half, with the remaining tasks from the first iteration placed into the
second iteration.

3. Requirements and Design

 3

The main requirement for the game was to provide the user with a scrambled word, and allow
the user to guess the word. The game would have to obtain a word from a words database,
scramble the word randomly, and allow the user to input his/her guess.
Another requirement for the game was to keep a database of high scores. If the user scores in
the top ten of all players, s/he should be able to input his/her initials, and the score and initials
should be saved in a database. The high scores page is accessible to the user at any point
during the game.
An example of a user story: As a <player>, I want to be able to <guess a word> so <I can score
points>.
As a <player>, I want to be able to <see high scores> so <I can know where I rank>.
As a <player>, I want to be able to <see a timer> so <I know how much time has elapsed>.

UML Case Diagram

 4

UML Sequence Diagram

Database design- ER Model

 5

Domain model
 6

Deployment Diagram

MVC
The servlet acted as an in-between with the view (the JSP files) and the model (the Game
object). The servlet, in essence, was the controller. The model, the Game object, contained the
logic for the game, and the view, the JSP files, provided a GUI interface for the user to input and
receive the data in a visual format. The servlet, or controller, served as the communicator, and
would forward user input to the Model and update the view based on the Models logic. For
example, when a game began, the Game object would obtain a word from the database and
scramble it. The servlet would then obtain that word, and pass it onto the view, to be displayed
to the user. The user can then input their guess, and the servlet communicates the guess to the
Game object, which will perform the logical operations necessary to determine if the guess is
correct, and if so, increment the score.
 7

Requirements change
The requirements did not change much, but many new requirements were added. We first
started off with just a game that would allow the user to input the unscrambled word and count
the guesses. Once that functionality was complete, we added on a timer. When that was
complete, we create a score calculator, that incorporated the timer into its algorithm. We then
created a high scores database that allowed the user to store their score and initials.

Non-functional requirements
We did not focus intensely on security, only choosing to validate the user input and make sure
they are not entering corrupt data. For performance, we tried to optimize the tools we were
using so that the program would run more fluidly. For example, we chose in some instances to
use JavaScript instead of Java or HTML because of performance benefits. We also tried to
make the interface as simple and intuitive as possible, so that any untrained and unintiated user
can still play the game successfully.