Introduction
The final category of evaluation in this class is the semester project. The goal of the project is to have you step through the process of an agile software life cycle to develop a concurrent software system. For in-class students, I would like you to work in teams of 2 to 4 students on this project. For CAETE students, you can work by yourselves, work with other CAETE students, or join a team of in-class students. (Please use the forum on D2L to facilitiate team creation.)
The first step of the software project is to identify an application that you would like to build that uses concurrency in some way and is scoped appropriately for the size of your team and can be realistically completed in the seven weeks of the semester that we have remaining (not including Fall Break). You will not be able to accurately simulate an Agile life cycle since you will not have a “real user” on your team. You will have to make due with being your own user.
You will have one week to identify a topic and to plan your release. Your release will consist of three 2-week iterations. At the end of the first week (October 24th), you will submit your initial set of (estimated, prioritized) user stories to Prof. Anderson along with your initial guess at your velocity and your initial release plan showing how your stories have been allocated to the three iterations. It's okay if the user stories for iterations two and three are less detailed than the stories for your first iteration. You're working with incomplete information and you'll get more information about your situation and what you're trying to accomplish as you make progress on your prototype.
Iteration Report
At the end of each iteration, you will submit a report that contains the following sections:
- Introduction: Provide a brief reminder of the purpose/topic of your project and in one or two paragraphs summarize what was tackled/accomplished during the iteration. Include a description of the current state of the prototype and what it can do. If you'd like to include an architecture diagram or class diagram of the work you've achieved so far, please do so, but these diagrams are optional.
- Previous Plan: Provides the list of stories that was assigned to this iteration. For iteration 1, this would be the stories assigned for that iteration in your release plan. For iteration N, it would be the stories assigned to iteration N in the iteration report of iteration N-1.
- Completed Stories: List of completed stories along with their associated tasks. For each task, be sure to list what estimate it received and which developer was assigned to the task.
- Incomplete Stories: If you started a story, but did not complete it. List it in this section along with its associated tasks. For each task, list its estimate and assigned developer and indicate whether it was completed or incomplete. (For instance, an incomplete user story with five task might have had tasks 1 and 2 complete, task 3 was in progress, and task 4 and 5 were incomplete.)
- Daily Burndown Chart: Include a daily burndown chart that shows the progress on the tasks associated with your user stories for that iteration. Only include completed tasks in this chart; do not include in progress or incomplete tasks.
- Iteration Burndown Chart: Include an iteration burndown chart that shows the progress on the stories in your project overall. Only include completed stories in this chart and only show the iterations that have been completed; do not include in progress or incomplete stories.
- Results of Spikes: If your team conducted one or more spikes during this iteration, describe the results of the spikes in this section in one to two paragraphs. In particular, describe what was learned and how that information will be used in subsequent iterations (if any).
- Updated Release Plan: Based on your progress to date, provide an updated plan for all remaining iterations (e.g. For Iteration 1, this section will include an updated plan for Iterations 2 and 3). Include with the plan, a discussion of how you dealt with incomplete stories from the current iteration… and discuss whether you have added new stories or if existing user stories have been removed.
- Miscellaneous: If you have additional information about your project/iteration not covered in the above sections that you would like to share, include it here. This section is otherwise optional.
- Conclusions: In this section, put into words what you have planned for the next iteration (if applicable) and what you hope your prototype will be able to do by the end of that next iteration. In other words, describe the intent of your updated release plan in natural language text. If this is your last iteration, then describe what else you would add to the prototype if you were to continue working on it.
The due dates for these reports are November 7th for Iteration 1; November 21st for Iteration 2; and December 12th for Iteration 3.
Project Suggestions
A reasonable goal would be to think of a combining the “batch style” concurrent programs that we have seen so far this semester with a user interface of some sort, such that a user can monitor the progress of a concurrent algorithm while it is active or the user interface is displaying some visualization that is being computed/generated by a pool of threads running in parallel. Other types of reasonable programs might involve the processing of data returned by web services in response to user-generated queries via some sort of interface or that involves a hybrid approach of both compute-intensive and IO-intensive tasks. Programs that concurrently process or analyze large scale data sets either stored in files or databases are also acceptable. I'm open to other ideas as well; if you have an idea that does not match these suggestions but still uses concurrency in some way, send it my way for review/approval.
Additional Details
- You should form your teams and send project ideas for me to review as quickly as possible. The release plan is due on October 24th but before you spend too much time working on it, make sure I've approved your project idea. Remember that project ideas should be scoped to the size of your team. A four-person team should be proposing more work than a one-person team.
- Fall Break occurs in between Weeks 13 and Weeks 14 of the semester and is not included in the above iterations. I WANT you to take a break that week; I don't want you to have to work on the project during that week.
- During the last week of the semester or during the first few days of Finals week, I will be meeting with teams to see a demo of your prototype and to receive your final report. The report will provide insight and information both about your prototype and its design/implementation as well as a final review on the agile life cycle you used to develop the prototype. More information on scheduling a demo and what should be included in the final report will be posted later in the semester.
- CAETE students working on their own or in CAETE-only teams will submit their final reports to me via D2L and will work with Prof. Anderson to determine how best to deliver your demo be it via a face-to-face meeting, a Skype video chat, a screencast, or some other mechanism. If your prototype is written in a language that Prof. Anderson can compile/execute on his machine, the demo can even be done by having Prof. Anderson run it on his machine while the CAETE student “drives” the demo over the phone.
- I will be reducing the intensity of homework assignments and quizzes to provide students enough time to work on the project.
This project is worth 100 points (50 points for the prototype and 50 points for the final report) and is worth 20% of your final grade.