This project was made for our CMPT 371 class – Software Management. The point of
the course was to create a software project with a group of 10 or so people. The course was
more about learning how to work as a team and to learn how to create such a large project, than
size or complexity of the software being developed.
Our software in particular was an Android game, called Luminance. We chose this
project largely because everybody in the group thought it sounded like a fun game. The game
itself is not original. It is a port from a version written in XNA by one of our group members.
We also saw this advantageous, as he had an in-depth knowledge of the system, therefore
making the port that much more straightforward to complete. The purpose of the game itself was
to be a simple, easy to pick up and play kind of game. It was meant to be a game that didn’t take
up a huge time commitment, but was still fun enough that it could be played for long periods of
time if the user so wished. Essentially, the game was made for casual gamers, and for more
hardcore gamers that would like a fun game on their mobile phone.
The teams for this class were set up by the professor. He chose who goes into what
group randomly. Amongst our team, we determined the roles each of us would take. Once these
were decided, we set up a VM with TeamCity to act as our continuous integration and build
management server. We used googlecode as our source code repository and issue tracker. We
also took full advantage their wiki functionality for any and all of our documentation. In
addition, we set up each member with the development environment on their home computers.
This included the Eclipse IDE, with the TeamCity plugin, Android sdk and the Android
emulator. In this way, every member could work on the project at their convenience at home.
We used this setup to our advantage. Whenever a member wanted to commit their code,
they were to do a Remote Run in their Eclipse development environment. If the build was
successful, their work would be committed. However, if their changes broke the build on the
TeamCity server, their code would not be committed. In this way, code that broke the build
would be prevented from being committed. Later on, we also set up a smoke test build which
would prevent the code from being committed if the project logically was not correct any more –
at least based on the unit tests that it consisted of.
In addition, if any issues were found they were to be immediately reported to the issue
tracker. This proved to be very useful, as emails about broken build or emails simply stating
something was broken were easily – and, quite often were – overlooked. In this way, the issue
would remain visible to all members until it was resolved, unlike emails which get pushed deeper
into your inbox as new emails come in.
Aside from the development environment, a process we undertook as a team which lead
to our success was our chain of command and improvement on communication. At the
beginning, we had a huge issue with both of these things. The work was centralized on one
person, and there was a lot of ambiguity in the group. We changed up some of our roles, and
from this point forward we made better use of the wiki for communication. As a whole, this
worked quite well. With our improved chain of command, our team leads oversaw their
respective teams, and ensured that everything that needed to get done did. The team leads
answered to the project manager, who oversaw the whole project.
- Kevin Stanley
- Qian Wang
- Merlin Hansen
Here is a list of things that was necessary to complete this project:
- TeamCity server set up on VM
- TeamCity plugin for Eclipse
- Google code repository
- ReplicaIsland open source input code
- Android emulator
- Android phones
This project was successful because:
- development environment
- continuous integration
- communication between members
- sharing of knowledge
- working together, skype
- coverage testing
- user evaluations
- Issue tracker
- the game itself!
Things that could have been better:
- devs maintaining their unit tests
- better organization of sprints (too much work left until last minute)
- new features; if less people could have made this game, we should have been able to
with more people and then some.
- enforcing smoke test – not useful if you don’t use it!
Things that we learned include:
- Don’t wait until the last minute to do something
- Double check deadlines
- Communication is key
- Partition tasks appropriately
- You’re working in a group; work AS group
- Don’t be afraid to ask for help
- Use any and all resources you need
- Allow for downtime. Get to know your group.
- Android sdk, openGL, TeamCity builds, etc.
Some things we will take away from this project:
- how to work as a team
- knowledge of many new things (Android, openGL, etc.)
- how to use a continuous integration server
- the value of using an issue tracker
Things to change
- implement smoke test early on, and enforce it strictly
- have devs maintain their unit tests
- research testability before engaging in a project
- research building before engaging in a project
- the background and context of this project. Why was it made, who was it made for, what is it's
purpose. This includes how the team was set up and the processes we used to lead us towards
completion. Essentually, write a comprehensive intro for this project.
- a list of things that were used for reference, such as any outside help we received. Kind of like
an unofficial bibliography. This includes help with bugs, setup, openGL, etc.
- List of essentual materials. This is probably straightforward, and we'll likely all end up with
most of the same things, but we certainly don't want to miss anything either.
- Describe what went right with this project. This can include successful techniques, materials
that should remain the same for a similar project. Essentually, in your opinion, what made this
- Describe things you think went wrong, what you would change in order to avoid this problem
in the future (if applicable)
- List the things you personally think you did well, as well as things you think you did not so
well. (I don't mean for these to be person-specific in the post mortem, I'm just trying to get your
brain working in the right direction for this document :))
- And, of course, what did you learn. What mistakes were made that impacted you and how you
will do things in the future. What things that were successful that you will take away from this
- Additionally, anything else you feel is significant to add to the document.