Software Engineering

Iteration 3: Early Development and Tests

Due on November 5th at 11:59 PM.

The master branches of your group’s repository and wiki will be pulled at that time and its contents will be graded. Be sure that all materials – documentation, code, build instructions, etc. – are available in that repository. If some materials cannot be placed in that repository, contact your instructor for instructions on how to compensate.

Please be sure to follow appropriate etiquette when interacting with your group.

Overview

The primary goal of this iteration is for your group to get a few core features working along with some passing unit tests. To work effectively, you will need to plan out what tasks need to be performed during each iteration. This plan will change significantly over the course of your project, but it will give direction and focus and help keep you on track.

Implementation Documentation

The implementation iterations are primary about developing your software, but it is still important to track and communicate your progress through a bit of documentation. For this iteration, you are expected to:

1. Form a project plan. You should do this before anything else. To accomplish this, you may use either a GitHub Project Board or a collection of GitHub issues together with milestones. Remember: this plan is not carved into stone, so you shouldn’t stress too much about getting it just right. Instead, it should be a guide that helps you think about how to divide up the work.

   If you use the project boards, you are encouraged to create a single project with one column for each iteration. Then, create a note for each feature of your application. (You should easily have a dozen or more notes. If you don’t, consider breaking your tasks into smaller parts.) Organize the notes under each iteration. Only create notes for your core features for now; you can add your extended features later if it turns out you have the time.

   If you use the issues and milestones, you should create one milestone for each of Iterations 3 through 6. You will also want to create an issue label for implementation issues. Then, for each feature (as in the above paragraph), create an issue in your repository, tag it as an implementation issue, and assign it an appropriate milestone. In this approach, we essentially view each not-yet-implemented feature as a bug and aim to correct it over time.

   The project board approach has the advantage that it’s easier to move notes between iterations. The milestone approach is useful because GitHub will automatically summarize progress on milestones. Pick the one your group prefers!

   In either case, your goal is to carve up the work you have yet to do and plan out your future. You’ll likely have to make changes to your plan as the semester proceeds and you learn more about your project; that’s fine!

2. Form an iteration plan. This is something of a side-effect of the above, but should be documented explicitly. Create an Iteration 3 page in your wiki describing the current state of your project and which features you hope to implement in this iteration.

3. Keep a changelog. You can start just by creating an empty file called CHANGELOG in the root of your repository. See Keep a CHANGELOG for information about how to do this effectively. You are required to keep a changelog throughout your project and all group members should be contributing to it.

Start Your Project

If you haven’t done so already, one of your group members should set up your project in your repository. This should take the form of an IntelliJ project created in the root of the repository. Only one group member will do this and then commit the results; the rest of you will pull that project rather than creating one of your own and you will all share this project as you proceed.

You should seriously consider creating separate modules for different parts of your project. You could, for instance, create a different module for each of your application model, persistence layer, server logic, and Android project (if all of those apply). This helps keep things cleanly separated and organized.

Automated Build

Your project is required to use an automated build system such as Maven or Gradle. By using a system like this, you make it possible for a user to build your project just by cloning your repository and running a single command. It also makes it easier to ensure that everyone in your project is having the same build experience.

If any environment setup is required, it should be described in README.md and should be as brief and simple as possible. For instance, you could ask the user to copy an example configuration file to a new location and set a username and password for a MySQL server. Nothing about compiling your code may be in README.md (except, if you like, a mention of the appropriate Maven or Gradle command). If you have any questions about what kind of setup steps are acceptable, please ask your instructor.

Unit Tests

Your project is required to use an automated unit testing framework such as JUnit or AUnit. By the end of Iteration 3, you should have meaningful unit tests of the functionality you have implemented and those unit tests should pass. It’s okay if you have some failing tests. Remember, however, that no feature is complete unless its tests are passing!

Deliverables

Store the above materials in your GitHub repository. The code you would like graded should be on the master branch of your repository as of the due date.

Iteration Review

You are also required to submit an iteration review which assesses the work you and your peers completed and whether things are going well for you in class. This review is private; its content will not be shared without your consent. Click here to submit your Iteration 3 review.

It is in your interest to provide honest feedback, even if that feedback isn’t the most generous or positive; if there’s a problem, your instructor needs to know!