Final Project ~ Fall 2019
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, developing it over three iterations, each of which will produce an
executable release.
Team formation
You will form your own teams. I strongly recommend that you form teams primarily based
around the times you are available, and secondarily around shared interests. We will form
teams as shown in the course calendar. However, you are welcome to begin discussing the final
project at any time.
Pitch
Each team will give a project pitch to the class as shown on the course calendar. It is 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. Note: Non-trivial games are strongly discouraged due to the fact that they
are deceptively difficult.
• Identify the target audience for the proposed project and the need that it addresses.
Depending on your application, you might 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 target audience. For example, “students” is too broad as it includes an enormous
variety of ages and cultures. “Non-traditional students at Ball State University” is a more
reasonable target, 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 strongly 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 strongly 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 using the following rubric.
Requirement Satisfactory (3) Probationary (2) Unsatisfactory (1) Unaddressed (0)
Summary statement
Target audience & need
Key features
Development &
deployment platforms
UI sketch or use case
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, each of which will be a few weeks long, as shown on
the course calendar. During each iteration you will create an increment of your project. Increments
are due before the beginning of class on the day that ends an iteration. See the course schedule for
these specific dates. You will submit these iterations via instructions provided in Canvas.
Project requirements
Technical requirements
• Each project is to be developed by a team of three or four students from the course section,
using an object-oriented approach and following the conventions for your chosen 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.
• Representatives of the target demographic (who are not also on the project team) must test
each increment. 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 occur during the class periods at the end of an iteration. Each
review 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.
Individual reflection essay requirements
At the end of each iteration, each team member will write a 300 to 600-word reflective essay on
the previous weeks covering this iteration. This essay should draw upon experiences from the
past iteration to directly and explicitly address one of the course's essential questions. You will
submit these essays confidentially in Canvas; they are not shared within the community, unlike
many of our other artifacts this semester.
Formal Evaluation
You will receive a grade for each of the three iterations of this project. Your grade for a given
iteration is the minimum of two iteration component grades: project, presentation, and individual
reflection essay grade and contribution grade. These two iteration component grades are
described below.
Project, presentation, and individual reflection essay grade
The evaluation for the project, presentation, and individual reflection essay takes place at two
levels of granularity. Your grade is the minimum of Step 1 and Step 2 as described below.
Step 1
The overall project system configuration is evaluated, along with your team’s presentation and
your individual reflection essay, in order to determine a maximum grade, using the following
specifications.
Maximum
Grade Project system configuration criteria
A
Project can be built without warnings or errors, and the rationale for any
suppressed warnings is clearly documented in the source code or README file.
Needed build instructions are provided in a README file. Contains unit tests for
all testable code of the model level.
B
Project contains compiler warnings, suppressed warnings are undocumented or
unjustified, or needed build instructions are not provided in a README file.
Contains unit tests for most testable code of the model level.
C Project can be built. Contains failing unit tests or few unit tests of the model level.
D
Project crashes during routine execution or contains no unit tests of the model
level.
Individual reflection essays will be evaluated holistically according to how clearly you connect
your experiences to the course's essential questions, and the quality of your writing, as described
above.
Presentation quality considers the quality of the presentation itself, based on evidence of having
met the criteria as described above for the following items:
• demonstration of project
• completed user stories
• product backlog
• critical component description
• acceptance testing results
Your maximum grade will be reduced by one letter grade if any of the following are true.
• You do not submit an individual reflection essay in a timely manner
• Your team satisfactorily completes three or fewer of the presentation items
• You submit an unsatisfactory individual reflection essay and your team satisfactorily
completes four or fewer of the presentation items
Step 2
The project source code will be evaluated following criteria from Robert C. Martin's Clean
Code. Keep in mind that Chapter 17 provides a valuable checklist. I also strongly encourage you
to use the Project Checklist provided in Canvas. The individual criteria for source code evaluation
(and their corresponding chapters in Clean Code) are:
• Meaningful Names (Ch. 2)
• Functions (Ch. 3)
• Comments (Ch. 4)
• Formatting (Ch. 5)
• Error Handling (Ch. 7)
• Unit Tests (Ch. 9)
• Classes (Ch. 10)
While I believe the big ideas of Clean Code and Test-Driven Development are holistic and
should be considered together, I also believe a finer granularity is appropriate when evaluation is
resulting in a grade. As such, I have itemized pieces below in the grade specifications.
If your submission includes or does all the following, you will receive a D or better for the
project source code grade. If all the specifications listed for a D are not met, you will receive
an F.
1. Submission will compile, run, and accurately satisfy more conditions of satisfaction of
the user stories than the previous iteration.
2. At least three of the following Clean Code/Test-Driven Development criteria (as
described above) are fully met:
a. Meaningful Names
b. Functions
c. Comments
d. Formatting
e. Error Handling
f. Unit Tests
g. Classes
3. At least three of the following technical requirements (as described above) are fully met:
a. Software architecture separates model from view
b. Project dependencies are tracked or automatically resolved
c. Project is hosted within the course’s organization on GitHub
d. README.md file with appropriate content exists
e. Production code is in the master repository branch
f. Release tagged as 0.1.0, 0.2.0, or 0.3.0, as appropriate
4. At least two commits were made since the last iteration, and the commits were pushed to
the course’s organization on GitHub.
If your submission includes or does all the following, you will receive a C or better for the
project source code grade.
5. All items listed above for a grade of D.
6. Submission will accurately satisfy at least one more user story than the previous iteration.
Additionally, a User Story document exists (in the team’s project folder in the course
Google drive) which documents User Story Names (USN) and their related Conditions of
Satisfaction (CoS). The status of each USN and COS should be indicated in some fashion,
e.g. with a completion date, or release number.
7. At least four of the Clean Code/Test-Driven Development criteria listed for a grade of D
are fully met.
8. At least four of the technical requirements listed for a grade of D are fully met.
If your submission includes or does all the following, you will receive a B or better for the
project source code grade.
9. All items listed above for a grade of C.
10. A few commits were made by many developers since the last iteration, and the commits
were pushed to the course’s organization on GitHub in a timely manner.
11. At least five of the Clean Code/Test-Driven Development criteria listed for a grade of D
are fully met.
12. At least five of the technical requirements listed for a grade of D are fully met.
If your submission includes or does all the following, you will receive an A for the project
source code grade.
13. All items listed above for a grade of B.
14. Many commits were made by the majority of developers since the last iteration, and the
commits were pushed to the course’s organization on GitHub in a timely manner.
15. Submission will accurately satisfy at least two more user stories than the previous
iteration.
16. At least six of the Clean Code/Test-Driven Development criteria listed for a grade of D
are fully met.
Contribution grade
Within twelve hours of your group’s presentation, you must conduct a rubric-based self- and peerevaluation
for each member in your group—including yourself, using the following rubric. A link
to an online form is provided in Canvas. If you do not complete this self- and peer-evaluation
within twelve hours of your presentation, I will reduce the number of requirements you complete
by one, which will result in a lower grade.
Requirement To satisfactorily complete a requirement, all listed items must be met
Commitment
Attended all scheduled group meetings (including group work times
during class) or notified the group in advance of absence. Absence(s) did
not significantly hinder the success of the group.
Participation Contributed to planning, research, implementation, testing, and
presentation.
Communication Clear, timely and accurate reports on what has been accomplished, what
is in progress, and what stands in the way, thereby facilitating progress.
Technical
contributions High quality technical contributions that facilitate success of the group.
Attitude and
Leadership
Listens to, shares with, and supports efforts of others, and actively tries to
keep the group together.
If more than half of your group members’ responses for a given requirement, including your selfevaluation,
are satisfactory, then you complete that requirement. Your contribution grade is
determined by the number of requirements you satisfactorily complete, based on the following
criteria.
Grade earned A B C D F
Number of satisfactorily completed requirements 5 4 3 2 1 or 0
Last revised: 08/14/2019.