Project Summary
For the software engineering capstone course at University of Illinois at Springfield, my team developed a version of the popular dice game Farkle using Java. This project went well beyond simply coding an application. It was an exercise in overall software engineering. In addition to coding, this project included overall project planning, team management, requirements documentation, design documentation, testing documentation, and user documentation. Our team was composed of three individuals that had never met prior to this project. We had to overcome hurdles of not knowing each other’s strengths and weaknesses at the beginning of the project, working remotely (we were in different time zones), and a compressed schedule to deliver the final project. This project represents one of the greatest learning experiences of my life.
The source code for this project is available on GitHub.
Project Plan
The project plan contains a short summary of the project, and detailed documentation of how we planned to completing the project. This plan includes a scope of work, individual responsibilities, a timeline for completing these responsibilities, and the tools and standards used to complete the project. The complete project plan can be viewed in its entirety on GitHub, granted it’s a large pdf that will have to be downloaded to view it properly.
Scope Statement:
The scope statement established the boundaries of the application we built. It provides a brief summary of how we planned to implement Farkle gameplay, as well as the programming language and software requirements for the project.
Organizational Chart:
The organizational chart depicts how our team was organized, and the role for each team member. These roles were decided at the beginning of the project before knowing each member’s strengths and weaknesses, and the responsibilities blurred as the project progressed. The team included three members: myself, Brant, and Curtis.
As the team leader, my responsibilities included overall documentation, and managing the project. I was responsible for tracking each members progress and ensuring the project stayed on track. I served as the liaison between our team and the professor, and provided him weekly updates on our progress. I organized and documented our weekly meetings, and kept everyone informed on the decisions made during these meetings. In addition to managing, I generated all documentation except for the majority of the source code.
As the lead architect, Curtis’s responsibilities included devising the overall architecture of the application, and helping with the source code. He effectively adapted the MVC architectural pattern to our application, and coded most of the GUI elements.
As the lead tester, Brant’s responsibilities included unit testing of the project, and helping with source code. He developed unit tests for some of the backend of the code base, and coded most of the backend elements.
As work progressed the lines blurred between our responsibilities. As the manager, I had to adapt the project as the strengths of each member became apparent. Curtis and I took over much of the testing responsibilities so Brant could focus on coding. After the first iteration, Brant took over much of the coding responsibilities including implementing new features, and fixing bugs. I took over the UML diagram generation to allow Curtis to focus on the GUI and testing. Had we known each other better at the start of the project, assigning responsibilities would have been a much easier task.
Gantt Chart:
We created and constantly updated a gantt chart in Microsoft Project throughout the project. This chart tracked each member’s responsibilities and progress throughout the project.
Tools and Standards:
The tools and standards document outlined the various tools and standards that were to be used throughout the project. This document detailed the programming language, IDE, version control system, collaboration methods, etc., and was used to ensure all members were on the same page.
To summarize this document, the project was written in Java version 1.7 using the Eclipse IDE. Version control was accomplished using Git with the EGit plugin for Eclipse. The main repository was initially stored on Google Code. Maven was used to automatically run tests and to package the application into a single executable file. The InstallShield plugin for Microsoft Visual Studio 2012 was used to create a .msi installer for Windows using the executable file generated by Maven. Code comments were written using the Javadoc standard.
Configuration Management Plan:
The configuration management plan detailed our plan for maintaining the various versions of the application that were developed. This plan outlined our chosen Git workflow, which included hosting the main repository on Google Code and branching this repository at the completion of each major interval. Furthermore, this plan outlined our documentation management workflow, which included storing and sharing all documents via Google Drive.
Programmer’s Manual
The programmer’s manual includes all information that a software engineer would required if he or she were to work on the project or maintain the code base. The complete programmer’s manual is available on GitHub, granted it’s a large pdf that will have to be downloaded to view it properly.
Requirements Documentation:
The requirements document is an extremely detailed list of the requirements for the final application. This document was judiciously followed by the programmers when developing the various features of the application. Each requirement was given a unique identification number that was used in source code comments for traceability.
Design Documentation:
The design documentation outlines the architecture of the application. These documents include a UML diagram, decision tables, and a control diagram, that together communicate how the requirements were implemented.
Testing Documentation:
The testing document formally lists every case that was carried out in testing. Each test case indicates the requirement that is being tested, the method used (black box, white box, or both), The rationale for the test, the inputs, the expected outputs, and whether or not the test passed.
Installation and the User’s Manual
Installer:
If you’d like to try out the finished application, feel free to download the Windows installer. If you’re not on Windows, you can fork the GitHub repository, and run it directly from source. Beware, the game is addicting!
User's Manual:
The user’s manual provides installation details and game instructions.
Lessons Learned
Early on, I discovered the importance of proper communication. We began the project with biweekly meetings where progress and responsibilities were discussed. I’d follow these meetings up with a written meeting minutes document that was shared via google drive, trusting that all team members would refer to this document throughout the week. This was a mistake made apparent when two team members separately worked on the same component of the application early in the project. This mistake made me realized that I had to email the meeting summary to each member to ensure they would read it and understand their assigned tasks for that week.
Another issue was the UML document. This document is extremely important when multiple people are working on the same project, but, in our case, it was not created until after the source code was finished. We chose to dive into the code instead of thoroughly thinking through the complete architecture of the application first. This led to confusing code that is difficult to follow, causing problems for code maintenance and new feature implementation. Should we have the chance to do this again, the UML document would be created before coding begins.
Finally, more time should have been spent determining the strengths and weaknesses of each member prior to assigning responsibilities. Ensuring team members are placed in positions that work to their strengths is crucial for a project’s success. Granted, this team was comprised of individuals that had never met, and this project had an extremely short schedule, rendering an adequate assessment of each team member nearly impossible. Should this team ever face a similar project, the responsibilities would be delegated differently to suit each member’s strengths, thereby increasing overall motivation and satisfaction with the project.
In summary, constant communication, as well as catering to team members’ interests and strengths, are crucial for the successful completion of a project. Overall, this experience was invaluable. These lessons will serve to greatly improve my future collaborative software engineering projects.