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 in three discrete iterations, each of which should result in an executable release.
You will form your own teams. It is recommended that you do this primarily around the times you are available and secondarily around shared interests.
Each team must register with the instructor by sending an email that provides all team members' names. They must address the required Project Design elements described below at time of registration.
Every team must identify their target demographic. Who are the people who will use this application? Depending on your application, you might need to consider factors such as age, gender, education level, interests/hobbies, native language, education level, 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: you can identify individuals readily for focus group discussion or acceptance testing.
Each project is required to have a summary statement, which is one or two sentences that succinctly describes the whole endeavor.
Each team will give a project pitch to the class. 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.
Pitches will be evaluated according to the following rubric.
| Requirement | Unaddressed (0) | Unsatisfactory (1) | Probationary (2) | Clearly satisfactory (3) |
|---|---|---|---|---|
| Summary statement | ||||
| Target audience and need | ||||
| Key features | ||||
| Schedule | ||||
| Development Platform and Release Platform | ||||
| 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 15. Revised pitches will be scheduled for the next possible class meeting. Once again, it is strongly advised that you discuss your project pitch with the instructor prior to delivering it to the class: having to complete a second pitch will eat into precious design and development time.
All projects must abide by the following non-functional requirements.
Each iteration must result in an executable release. This means that anyone should be able to download your project from the repository, compile it without errors or warnings, and run the application without encountering any problems. That is, each iteration produces a potentially-shippable product whose features are complete. Put another way, there should be nothing in an executable release that is incomplete: it is complete working software. Note that this is an essential practice of agile software development.
Each executable release is to be tested with potential end users chosen from your target demographic.
Executable releases are to be tagged in the repository at the end of each iteration according to the following schedule.
| Iteration Number | Tag |
|---|---|
| 1 | 0.1 |
| 2 | 0.2 |
| 3 | 0.3 |
Iteration reviews will follow on the two class periods after the end of an iteration. Each review may be no more than ten minutes long and must address the following.
At the end of each milestone, you will receive a formal evaluation that covers both your iteration review presentation and the executable release itself. The evaluation will include the following elements.
I will be using my usual triage grading approach. Briefly, each component of a submission to be one incorrect (1/3 points), partially correct (2/3 points), essentially correct (3/3 points), or not done (0/3 points).
Your iteration review presentation will be evaluated on the criteria listed above, with three points per criterion. The executable release will use a weighted scheme as described in the following table.
| Criteria | Points |
|---|---|
| Clean Code: Structure | 9 |
| Clean Code: Process | 9 |
| Version Control | 3 |
| Project Configuration | 6 |
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.
| 3 | 2 | 1 | 0 | ||
|---|---|---|---|---|---|
| Commitment | Attended all scheduled team meetings or notified the team of absence. | Missed team meetings, with notifications, with enough regularity to be problematic. | Missed one or more team meetings without notifying the team. | Regularly missed team 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 | Clear 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. |
We will define your raw iteration grade as 15% presentation and 85% project. Then, your iteration grade is the minimum of your peer evaluation score and your raw iteration grade.
Your final project grade will be a composite of all three iterations, 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. This scheme accounts for your team to get better at working together as the semester progresses.