Professional Documents
Culture Documents
Finalreport Ken Vader
Finalreport Ken Vader
Finalreport Ken Vader
CST-438
Professor David Wisneski
12/16/16
Final Project Report
For our team project, we chose to make a version of Rock, Paper, Scissors
that would have game elements beyond just the initial selection of rock, paper, or
scissors. We wanted to have different game modes that would add more depth to
We considered many different game types, including a 2-player mode, a player vs.
computer mode with health bars, best 2 out of 3, and a story mode that required a
certain number of wins to move to the next part of the story. Some of these ideas
required more time than we have available to implement them, so we chose to start
with the player vs. computer with health bars as a starting point and see how much
we could get added in after that. We will also be including some statistic tracking,
both for the current session and across multiple sessions. Our project will be using a
SQL database to store the statistics between sessions, and we will use JPA to handle
Code quality is a way of measuring many aspects of a code base. How easy
the code is to read, how well named the variables, classes, and methods are, the
complexity of the code and the comments to explain those sections, and adhering
to a design pattern are all factors in making good quality code. Creating good
quality code results in an application that is stable, secure, and easy to use. While
there will always be differences of opinion on the specifics of formatting code, good
quality code always sticks to a consistent format. Avoiding spaghetti code and
adhering to well defined design patterns also contributes to good quality code. Code
should be self-documenting, but with comments where they are needed to explain
more obtuse sections. Teams should strive for their code to be readable and
On our project, we utilized several tools and employed some best practices to
help us create good quality code. We made use of a Github repository to allow us to
work on a single version of the project with no confusion as to what the latest
version is. We also took advantage of Pivotal Tracker to help us organize our
workflow. Pivotal allowed us to brainstorm and prioritize in the same tool, while also
giving us a place to see who was currently working on what. Of all the new tools
that we were exposed to in this course, Pivotal was by far the most useful and
easiest to use. Our team employed code reviews to ensure that any code we
produced was not only bug free, but also easily readable. While writing code, we
wrote unit tests which were also committed to the Github repository to allow for
regression testing. Our project was a simple one, so keeping the code clean and
simple was a big part of our mission. Keeping our code base stable by thoroughly
Team velocity is a way to measure how much work a team can get done in a
how much time it should take to complete said task. At the end of an iteration, the
numerical values are summed, resulting in that iterations velocity. These velocity
values can then be used to plan future iterations, make more accurate estimates on
when work will be completed, and estimate overall project completion date. On our
project, it was helpful to see how quick work was being done over a week, allowing
This project makes use of the MVC pattern by keeping all of the logic in the
.java servlet files, the view is taken care of in the. jsp files, and the model is handled
by the SQL server. We did not end up using JPA to handle the database objects and
communication, but rather wrote some simple SQL statements into some methods
that we could re-use. The methods handle database connections, reading to the
database, and writing to the database. Keeping our design consistent with this
pattern helped prevent the spread of spaghetti code and made refactoring easier.
As we progressed through each iteration, by using the MVC pattern it was also much
clearer where to add certain components when we wanted to add a feature or alter
the design. Had there been a longer timeline to plan prior to beginning the project,
we may have elected to use additional patterns. However, at this time MVC is the
If given the opportunity to begin again, one of the things our team would
change would be the priority we put on getting the database section running. In
hindsight, it would have made more sense to start from a simple database web
application and expand out from there. In the end, it will not affect the final product,
but it would have simplified some parts of the development process. Another area
Pivotal and had our stories and tasks entered, but there was not enough ownership
of tasks throughout the team. It would have made more sense to have us each
commit to at least one actionable code item per sprint, and then pick up more if we
Hangout chat sessions and a little bit of email. We did speak throughout the week,
which was great. Everyone on the team was quick to respond to messages, which
made working through issues much easier. We did not have enough formal team
their part in the project and helped keep everyone on the same page. Doing this via
a video conference would also lead to more ownership and accountability regarding
The communication issues that we did have, mostly in the form of no formal
meetings, likely caused a disconnect in the expectations of what was required from
each team member. With that in mind, if we were to do this project again, it would
make sense that the first order of business would be to agree on a set meeting
schedule for the life of the assignment. We could have planned twice weekly video
conference meetings, scheduled to only last 15 minutes, where we would have the
opportunity to talk about what we are working on and ask questions about what
others are working on. This would facilitate adhering to the Agile methodologies
that we learned during this course and also make it possible to have concrete
ownership of tasks. It would also be a forum for team members to talk about where
they are having difficulties and ask for help, or to talk about their successes and
some of this with a Waterfall methodology, but it would have required a significant
amount of time to plan and many meetings for us to settle on the design. In the
end, the Agile methodology was the right choice for this project, as it allowed the
design to evolve as we saw working prototypes and made decisions based on that
rather than theory. There was not anywhere in this project that a Formal process
would have been needed, and it likely would have just slowed things down and
gotten in the way of the development cycle. The needs of this project are such that
a Formal methodology would have been overkill. Perhaps, in the future, if we had
process would make sense. When dealing with money, it would seem prudent to
make sure there are no errors anywhere in your code that could cause severe
possible and then use comments in places where the intent might not be as clear.
There were only a couple of places where we felt comments were strictly necessary.
The code is well organized and easy to read, with meaningful names for the
themselves with the code in short order and there would be little confusion on how
We have so far needed to refactor the way we handle single sessions and the
way we handle a game loop. We initially had one class that was handling holding
the session stats and a game loop inside of the post method of our Java servlet
file. We have decided to shift to a class to hold the stats, a class to handle the
players playing, and keep our game loop where it is but make use of the two
refactored classes. This will make it easier to add other game modes, as well,
because the player and stat keeping classes will be independent of each other and
This project has been a great learning experience. It provided the opportunity
technologies that I may not have looked into on my own. I plan to use the project
going forward as a testing environment to get more familiar with Java and J2EE. The
exposure to new frameworks and design concepts will transfer to other languages