Software Project

Introduction

Students this semester have the choice of conducting a fast-paced, 3-week long semester project in place of one of the four presentations that are otherwise due for the semester. The goal of the project is to have you step through the steps 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 three weeks of the semester. 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.

If you decide to take this option, you can choose when in the semester you would like to run your 3-week development cycle. At least one week (preferrably two weeks) before you start, you need to identify a software system that you would like to create and send a description of it to Prof. Anderson. The initial document is your chance at practicing an agile technique known as release planning. In this case, your release will consist of three 1-week iterations. In your plan, you will describe your system along with an initial set of estimated, prioritized user stories along with your intial guess at your velocity and a table showing how your stories have been allocated to the three iterations. In addition, you should have created tasks for the stories that are in week 1 and have assigned those tasks to members of your team. It's okay if the user stories for iterations two and three are less detailed than the stories for your first iteration. You'll be working with incomplete information with respect to those stories 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. Include architecture and class diagrams of the prototype alongside your textual descriptions to help make its state more clear.
  • Previous Plan: Provide 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 not completed. (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 in this chart's numbers.
  • 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 in this chart's numbers.
  • 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 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 the next iteration. In other words, describe the intent of your updated release plan. 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 dependent on when you start your project, but I expect that teams will start their iterations on Monday and send me their iteration reports on the following Sunday. When you have finished your project, you will need to schedule a meeting with Prof. Anderson to show him your developed prototype.

Project Suggestions

A reasonable goal would be to think of combining the “batch style” concurrent programs that we will see 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 by week 9 of the semester. That will give you four weeks to get your project launched. Your project has to start no later than week 13 in order to be done by the last week of the semester. Preferably, teams will launch their project by weeks 10 or 11 so they will be done well before the end of week 15. 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.
  • 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.

This project is worth 200 points (50 points for each iteration report and 50 points for the final prototype) and is worth 10% of your final grade.


© University of Colorado, Boulder 2015