This project steps learners through a series of assignments that culminate into a photo viewer/archive tool. The assignments are designed to emulate a software development "sprint" in the Agile development process parlance. Each sprint consists of an assignment that builds off the code of the previous assignment, and is by itself a valuable piece of the overall end product.
Our aim is to give students the feeling and experience of working on a large project via a sequence of carefully-crafted homework assignments. This project helps students gain experience with Object Oriented Programming in Java, combined with software development techniques, commenting and documenting code for maintenance, unit testing with JUnit, exception handling, event-driven programming and use of pre-built Java Swing components. The project culminates in a fully-functional graphical user interface and leaves plenty of room for creative expression.
The project was designed and developed with a neutral position regarding gender, race, and other protected classes. We believe the end product has a universal appeal for users of technology and the potential software developers of tomorrow.
For the first three sprints, we provide both the description of the assignment and a set of JUnit test cases. In each of those sprints, we had students write their code in Eclipse and then submit to WebCAT, an auto-grading website built by Virginia Tech. WebCAT runs the tests over the student code, and auto-assigns 70% of the grade for the assignment where each test is worth an equal portion of the grade. While WebCAT provides immediate feedback and allows for resubmission, we encourage students to thoroughly test their code first and subsequently limit the number of resubmissions in each sprint. For institutions without access to a tool such as WebCAT, the tests can be run locally over the students’ code and a grade assigned based on the percentage of tests passed. We also leave 30% of the grade for inspection for best coding practices, such as naming conventions and documentation.
We provide two options for the last sprint. The first, Sprint 4, provides scaffolding code to guide the students in building the GUI, requiring the event handlers and some Swing development and encouraging students to modify the design for extra credit. The second option, Sprint 4+, encourages creativity by designing an entire GUI, but has a steeper learning curve. In either case, we manually graded each assignment to assess the Graphical User Interface developed by the students. We suggest requesting a screenshot from the students along with the submission of their code, since we have found discrepancies in the display across platforms and display types (such as 4K or retina displays). For Sprint 4+, we suggest more flexibility in grading to account for the student choice provided for in the GUI requirements.
Since this project is a series of sprints that build into the larger deliverable, it is possible for a student to fall behind early on in the series. We found this to be the biggest pitfall of the assignment and we suggest putting into place measures to avoid that scenario:
- display due dates of all sprints up front so that students can prepare for the upcoming milestones,
- provide a representative subset of the test cases in the middle of the project (after Sprint 2) so that students can see both the results of the tests and how their code is being used by the auto grader,
- only test the newly implemented features required in each sprint for a grade (this is accomplished in our provided test cases), and
- hold review sessions after each sprint so that students can ask general and conceptual questions about what is expected of them.
We also expect that the project could be shortened or modified to meet requirements of different courses. The project could be truncated at any sprint and used as a smaller set of homework assignments, such as removing the event-driven GUI assignment. The last sprint may also be replaced with an Android application task, requiring the students to apply their data model as the foundation for a mobile photo management software. We suggest Android, since the Java model can be directly used by the developed app as it can in the Java Swing desktop version.
Through the series of assignments, the students build a photo viewer and archive application, which is relevant to their daily experiences with apps such as Instagram, Facebook, and SnapChat. As the project progresses, the sprints incorporate student choice. Sprint 4 provides students some freedom to interpret the GUI software requirements to build an application that expresses their personality and personal design preferences. We also provide Sprint 4+ as a substitute for Sprint 4 with additional flexibility. Our GUI mockup for the final product expresses the diversity of contributors to CS in the included photos.