CS222 Spring 2015 Section 1: Final Project Requirements

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. It is recommended that form teams 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.

Pitch

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.

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 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 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.
Share the user stories of your proposed project, including their conditions of satisfaction. Use Mike Cohn's format. Provide the user stories in priority order (the "product backlog"), and clearly indicate which subset of them you expect to satisfy by the end of the first iteration.
Describe the technology you propose to use to complete this project. Java and Eclipse are recommended but not required; using an object-oriented paradigm is required.
State the platform on which you will release your project. 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 clients for a library or Web service.

Pitches will be evaluated according to the following rubric.

Requirement	Unaddressed (0)	Unsatisfactory (1)	Probationary (2)	Clearly satisfactory (3)
Summary statement
Target audience
Product backlog (prioritized user stories)
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 12. Revised pitches will be scheduled for the next possible class meeting.

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. 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). An exemption will be made for strictly view-level code, which does not require TDD.

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.

All project dependencies that are not part of the development platform must be either tracked in the version control system or automatically resolved using a dependency management system such as Maven. If your project has any special build requirements that cannot be managed otherwise through the version control system, these are to be documented in a README file that is located in the root of the project directory hierarchy. This file may be in plain text or markdown.

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.

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.

Each project must use Mercurial for version control, with the project hosted on csmerc-2 as a public project. 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

You are welcome to use the project checklists to help your team in reviewing its work.

Presentation Requirements

Iteration review presentations 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.

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 writes a reflective essay on the previous three weeks. This essay should directly address one of the course's essential questions, drawing upon experiences from the iteration. 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.

	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.

Your contribution score is the sum of the medians from this rubric, and your raw iteration grade constitutes 10% presentation, 10% reflection essay, and 80% project. Your grade for the iteration is the minimum of these two.

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.