Brett Hansen

CST 438
12/6/16
Fall 2016 Project Report
This project is a web based sales analytics application. The basic idea is that visiting a
webpage will trigger JPA style code that will query a SQL database containing sales, employee,
and product information. Then based on what the user wants, the site will display statistics and
graphs that give an intuitive summary of the data. As was mentioned in the group meeting with
the professor, the goal of this project is to make a mini salesforce style application that would
give managers an idea of what products sell at any particular time, and which employees are
responsible for their sales in a particular timeframe. Matt actually came up with the original
product idea as he does similar things in his job. This ended up in my alley since Ive done a fair
amount of reading on data visualization. Throughout the project weve done a fair amount of
work into making a quality code base to work off of.
Quality code in this case means a few different things. One of the most important things
in quality code is that it is self-evident. By this we mean that in the words of the agile manifesto,
code is the best documentation. If code is written very well, it is fairly intuitive and the
commentary becomes more like signposts rather than necessary explanations of obtuse or
obfuscated code. Secondly, quality code is as elegant as possible in the mathematical sense. By
this we mean that the code is exactly as simple as it needs to be, but no simpler. Any unnecessary
complexity is shunned in favor of the most efficient and cleanest solution. Lastly, quality code
must be able to pass through rigorous quality testing. In this projects case, this means automated
Junit testing with as many tests as is feasible and necessary to ensure proper functioning under a
wide range of inputs. We only began implementing unit testing in iteration 4 with manual testing
being done in previous iterations. Additionally, we should have begun formulating a stronger
cohesive structure (and discussed the relationships between our individual work and the classes
we were building) earlier in the process as this would have saved us time and effort in the long
run. In the interest of speed, we also could have done a better job of tracking velocity in order to
better estimate the length of certain tasks.
Team velocity is a measure of the speed with which a team can move through tasks. It is
usually measured by the number of tasks that have been completed in the previous few iterations.
The best way for us to better track velocity would be to more thoroughly embrace pivotal tracker
and break stories into smaller user cases rather than larger technical problems.
A few of the user stories of interest would be user must be able to pull up lists of sales
and users must be able to generate graphs of the sales data. For the sales lists, this is largely
accomplished by having a sales extract class that pulls the data from the MySQL database using
JPQL calls and then uses parsing to pump the data into readily built classes for sales, employees,
and products. As for the graphing story, this is accomplished through the use of the extract data
functions that return data in the form of compound maps and then using a graph class to turn that
data into graphs using the JFreeChart library. These model objects are stored as PNGs which are
then displayed by the view segment of the project.
In starting this project over, I would definitely focus on stronger organizational planning
the beginning. In particular, I would thoroughly outline what we want to accomplish and then
give everyone 2-3 days to research all aspects of the project so we could then come back and
from a more informed perspective setup our backlog of user stories and accurately define the
scope and bounds of work. Additionally, setting up unit testing from the get-go would have gone
a long way towards standardizing class output. One problem I personally ran into was having to
write a class with no idea about what form the data I was going to be working with would take.
In the end I had to rewrite large chunks of code as the way I was parsing through data wasnt
workable. Another way to improve would have been working harder to build momentum at the
start of the project (updating pivotal Tracker daily and pushing updates to the GitHub repo every
day or every other day rather than 1-3 times a week). In a nutshell the biggest changes would
have been in planning and making small iterations constantly rather than fewer larger changes.
Our team communicated largely via text. In particular, we used google hangouts as a way
to keep in touch as well as asking and answering small questions. In addition, we also used email
as a way to keep in touch, sending to dos and notifications about work completed. We didnt
necessarily use pivotal tracker as a method of intra-team communication. We would send
messages on hangouts at least once a day, send an email every couple of days and have a weekly
face to face meeting. For meetings we used the hangouts talk feature to meet and discuss what
we did in the current iteration and what we hoped to accomplish in the next one.
As I previously mentioned, there were a few issues related to less communication or
rather, less effective communication than would have been optimal. Had we done a more
thorough job of planning & requirements gathering/class planning in the beginning, we may have
had an easier time of working together and making interconnected segments of the project. For
me personally, I know that I built the graphs class with manicured arrays in mind and had to
tweak a fair number of things once I realized that we had nested maps coming back instead. We
also had a couple of limits in our understanding of the technology. Early in the project we had
expected to be able to do a lot of our data analysis using SQL. Unfortunately, we didnt take into
account the fact that JPQL has some limitations in comparison to MySQL (a language we were
more familiar with). As a result, we had to switch partway through to doing the data analysis in
Java based off sheer text dumps of the database. This was a significant refactoring and pivot in
the process.
The requirements remained fairly consistent throughout the development process. That
said, the methods used to meet those requirements did change quite a lot over the course of our
four iterations. In this particular case, a waterfall method would not have worked particularly
well as our understanding of the project and the process it would take to complete was limited in
the beginning. This project was a learning process and as such we ended up with a very different
design process than was expected.
As I previously mentioned, I wish that we had more rigorously defined and planned the
components of the project prior to engaging in work. In particular, it would have been nice to put
formal methods to use in defining the interactions between the model and controller classes as
well as the web based pathing.
At this point in the project we are still going back to document our work in order to make
our code easier to maintain. By the end of this week we should have a thoroughly documented
project that would let a new programmer onboard fairly easily. All they would need to do is read
the class documentation and review the code base as it stands now.