Final Project: Introduction
Your final project will be your focus for the majority of the semester. You will be working with a team on your own project over three iterations, each of which will produce an executable release.
Team Formation
You will form your own teams. It is recommended that form teams primarily around the times you are available and secondarily around shared interests. Teams will be formed during a class meeting that is tentatively scheduled for September 26. However, you are welcome to begin discussing the final project at any time; feel free to use the general discussion forum on Blackboard to initiate conversation with classmates.
Pitch
Each team will give a project pitch to the class, tentatively scheduled for September 28. It is strongly recommended that you review the pitch requirements with the instructor prior to your pitch. The presentation may be at most five minutes long. Slides are optional and handouts are encouraged. The pitch must satisfy the following requirements.
- Share a project summary—one or two sentences that succinctly and accurately describe the endeavor.
- Identify the target audience for the proposed project and the need that it addresses. Depending on your application, you may need to consider factors such as age, gender, education level, interests/hobbies, native language, and access to technology. This identification must be specific enough to allow you to test your project with representatives from the audience. For example, “students” is too broad as it includes an enormous variety of ages and cultures. “Non-traditional students at Ball State University” and “Chinese Computer Science majors in the 1+2+1 Program” are both more reasonable targets since you can unambiguously identify individuals for focus group discussion or acceptance testing.
- Briefly describe one to three key features of your proposed project.
- State the technology you propose to use to complete this project. Java and IntelliJ IDEA are recommended but not required; using the object-oriented paradigm and GitHub are required.
- State the platform on which you will release your product. Desktop applications on the Java platform are recommended but not required. Attempting to support multiple platforms is strongly discouraged.
- If the project has a user-interface, provide a sketch or mock-up of it. If not, provide examples of the use case for your project, such as sample API calls for a library or Web service.
Pitches will be evaluated according to the following rubric.
| Requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unaddressed (0) |
|---|---|---|---|---|
| Summary statement | ||||
| Target audience | ||||
| Key features | ||||
| Development and deployment platforms | ||||
| UI Sketch or sample clients |
A team must repeat their pitch if they earn 0 or 1 point in any category or if total points is less than 12. Revised pitches will be scheduled for the next possible class meeting.
Schedule
The project is divided into three iterations, during each of which you will create an increment of your project. Increments are due at 8AM on the day that ends an iteration; these will be submitted via instructions provided on Blackboard.
- Iteration 1
- October 3 to October 24
- Iteration 2
- October 26 to November 14
- Iteration 3
- November 16 to December 7
Project Requirements
Technical Requirements
Each project is to be developed by a team of three or four students from the class, using an object-oriented approach and following the conventions for your language.
Your software architecture must separate model from view, as well as the persistence layer if you have one. This should be done using a domain model—an object-oriented representation of the concepts and relationships manifest in your problem domain.
You must follow the principles of Clean Code, including structural principles (such as OOP and SRP) and process principles (such as TDD and the Boy Scout Rule), although strictly view-level code does not require automated tests.
All project dependencies that are not part of the development platform must be either tracked in the version control system (such as in a lib folder) or automatically resolved using a dependency management system such as Maven or Gradle.
All projects will be hosted within the class' organization on GitHub. Each will have a README.md file in the root of the repository that lists the team members and any special build or execution instructions.
Your production code should be in the default repository branch, which is called master.
Each iteration should produce an executable release, also known as a potentially-shippable product. That is, your increment should be a usable, stable software system that implements a subset of your product backlog. The three releases will be tagged using semantic versioning as 0.1.0, 0.2.0, and 0.3.0, respectively.
Each increment must be tested by representatives of the target demographic who are not also on the project team. This practice constitutes acceptance testing, and it is done by giving testers specific tasks to accomplish using your system and observing their interaction with your system. The tasks should come from your user stories.
Presentation Requirements
Iteration review presentations will be be held the day the iteration ends. Each presentation may be no more than ten minutes long and must address the following.
- Demonstrate the executable release.
- Describe the user stories that were completed and any changes that have been made to the product backlog. If this is not the final iteration presentation, indicate which user stories will be accomplished during the upcoming iteration.
- Describe a critical component of your system that was developed during the previous iteration. This is an opportunity to share something interesting with your classmates outside your team. You are expected to show and describe the implementation of this component.
- Summarize the results of acceptance testing.
Reflection Essay Requirements
At the end of each iteration, each team member will write a reflective essay on the previous three weeks. This essay should draw upon experiences from the past iteration to directly and explicitly address one of the course's essential questions. These essays will be submitted confidentially on Blackboard; they are not shared within the community, unlike many of our other artifacts this semester.
Grading
Each increment will be evaluated in two categories: code quality considers the quality of the code itself, including project configuration and version control configuration, and process quality considers evidence of procedural correctness, including TDD and version control practices. Your presentations will be evaluated based on evidence of having met the criteria for the demonstration, product backlog, critical component description, and acceptance testing results. Your individual reflection essays will be graded holistically according to how clearly you connect your experiences to the course's essential questions.
Each member of a team will also conduct a rubric-based self- and peer-evaluation at the end of each iteration, using the format given below.
| Requirement | Satisfactory (3) | Probationary (2) | Unsatisfactory (1) | Unacceptable (0) |
|---|---|---|---|---|
| Commitment | Attended all scheduled meetings—including class meetings—or notified the team of absence. | Missed meetings, with notifications, with enough regularity to be problematic. | Missed some meetings without notifying the team. | Regularly missed meetings without notifying the team. |
| Participation | Contributed to project planning, implementation, testing, and presentations. | Did not contribute to one of the following: project planning, implementation, testing, and presentations. | Did not contribute to two of the following: planning, implementation, testing, presentation. | Did not contribute to three or more of the following: planning, implementation, testing, presentation. |
| Communication | Clearly reports on what has been accomplished, what is in progress, and what stands in the way, thereby facilitating progress. | Sometimes is unclear about what has been done, what is in progress, and what stands in the way, creating minor impediments to progress. | Is regularly unclear about what has been done, what is in progress, and what stands in the way, creating significant impediments to progress. | Communication patterns directly disrupt team progress. |
| Technical contributions | High quality technical contributions that facilitate success of the team. | High quality technical contributions that do not directly facilitate the team's success. | Low quality technical contributions that frequently require redress by other team members. | Low quality technical contributions that inhibit success. |
| Attitude and Leadership | Listens to, shares with, and supports efforts of others, and actively tries to keep the team together. | Listens to, shares with, and supports the efforts of others. | Frequently fails to listen, share, or support teammates. | Displays an antagonism that inhibits team success. |
Your contribution score is the sum of the medians from this rubric, and your raw iteration score constitutes 10% presentation, 10% reflection essay, and 80% project. Your grade for the iteration is the minimum of the contribution score and raw iteration score.
Your final project grade will be a composite of all three iterations grades, each being weighted by the square of the iteration number. That is, your first iteration contributes one unit, the second contributes four, and the third contributes nine.