Final Release
This is a team assignment; each team submits one assignment
Due Date for Final Deliverables: As specified in bidding stage, 23:59:59 EST (No late submissions will be accepted).
Demo Date:Saturday, November 30
Weight: 20% of course grade
Submission format: commit all necessary files to your team GitHub repository by the deadline.
The main goal of the final milestone is to finish your project and deliver a screencast showing off the key features of your software. This will involve the following:
All work artifacts should be checked into the repository throughout the sprint. Time stamps and versions will be used especially to evaluate process tasks.
Submit your running code along with clear, explicit instructions for how to install and run it. Make sure you include appropriate test cases.
As this is the final iteration, credit will be given for tidying up your repository. Stuff that's only half built or that doesn't work should be cleared off to a branch - the trunk should only contain things that are properly tested. You should have enough test cases to convince your TA that all of the functionality in the released version does actually work.
Depending on the software that you created, one or both of these items may need to be completed.
Create an installer for your software. This can be an executable or a script, but should only require double-clicking on a single program.
Deploy your software to the client site. Make sure that your Product Owner has a running version of the software installed in their machine or server. If this is not possible before the assignment deadline, provide a plan for deployment before the end of the exam period.
Include a short but clear user guide, explaining what your product is for, and how to use it. All features in the final release version of the software should be described. Include clear installation instructions, including details about which platforms it will run on, and any other packages that it relies on. (Bonus marks for a troubleshooting guide!)
Also, include your developer design document. It should contain a brief summary of the architecture of your software, describe how is the code organized into modules, how it interfaces with existing libraries and support software, and any known bugs. Write release notes: list the features that are included in the current release, and describe any known bugs/weaknesses (you can also mention things that ought to be addressed in the next release). The target audience for these parts of the documentation is other programmers who might have to maintain/adapt your code later.
For next year's CSC301H class, the instructor needs to find additional customers. To do this, she needs some material for bragging about your team's project.
This should be a short video (aim for no more than 5 minutes) showing off what your software can do. Think of it as an advertisement for your software (like a trailer for a movie): you don't have to get every detail of the software into the screencast, but you should show enough to get people interested to want to try it. It works best if you tell a story - rather than just showing a feature, explain why people would want the feature, and how they would use it. Suggestion: use the personas and user stories you generated in Sprint 1 to make the story more interesting.
There are a number of tools for producing screencasts. Use one. Wink has been recommended for this in past versions of the course. Microsoft Expression Encoder 3 Screen Capture is also available for free for students through Microsoft's Dreamspark website (http://www.dreamspark.com). Camtasia is also good software for this, and trial versions can be downloaded from their website as well.
Produce a presentation consisting of 5-7 slides that describe your software product. You may use PowerPoint or Keynote. These slides should describe the purpose of your software, the technology that you used to create your product , and its key features. The presentation should include visual elements, such as screen shots, photographs, and diagrams.
Reflect on your development processes over the entire term. List the tools and techniques that you used, and describe their effectiveness. List also the things you didn't do, and comment on whether, in hindsight, you made the right decision not to use them. Bear in mind that no tool/technique/process will be perfect for every context. Hence, reflect on your particular context (e.g. team software development in a university course), and think about how well things recommends in books and in the lectures actually worked for you. Credit will be given for insightful reflections on what you've learnt from problems you encountered. Credit will not be given for pretending you followed a perfect agile process model and everything went fine.
Keep minutes for your meetings. Minutes should include a list of who attended, what decisions were made (and how), and a list of action items (with deadlines and who they were assigned to.) Also, create a spreadsheet showing who attended which meetings. (Make each meeting a column in the spreadsheet.)
Give a 15-minute demo in class consisting of the following elements: screencast, live demo, and an install demo. It is recommended that two computers be used for the demo; start the install or build on one machine, play the screencast on the other machine, and return to the first machine for the remainder of the demo.
Final versions of all deliverables are due on various dates established during project bidding.
Submission will be through GitHub.
Demos will take place on Saturday, November 30.
Create a web page for the Final Release. From there add links to all elements that you want graded. Many of the links will be to your group's github repository. This includes meeting minutes, notes about your conversations with the customers, test plan, test code, user stories, source code, and any other explicit and implicit deliverables.
The above requirements are subject to changes based on feedback from the course bulletin board. This page will be frozen at midnight on Friday, November 22.