CS 240 - Integration Demonstrations

Due date varies

Overview

Over the course the project's implementation, you will be giving a nubmer of short demonstrations of your progress. At each demo you will be presenting a build of your module "so far". Each build should be functional; these demos will thus be similar to the iterative/agile methods we've discussed in class (with each demo representing the end of a short "sprint"). These demos will act as "check-ins" to make sure your development stays on track.

Moreover, these check-ins will give us a chance to do integration testing---to make sure that all teams' modules are able to effectively integrate and connect with the others. In short, these integrations will let us see early builds of the entire system as implementation is completed.

Objectives

Coordinate with other teams about overall project requiremenst and goals.
Experiment and practice with a development process akin to "sprint-based" agile development.
Practice giving in-person demos showing off work completed so far.

Details

For each demo your team will need to commit your current working code to the main branch of the project repository. The demonstrated code will be checked out of that branch and run on a single central machine (likely the smart-room's system or the professor's laptop), so that we can see the entire system in action. Thus your code needs to be stable enough to be run!

Note that you should include any "build instructions" in the repository's readme.

We will devote an entire class day to these demos. The day will work as follows:

You will have 15 minutes of class time to make sure that everything runs on the demo machine, and to add in last minute hotfixes if needed. Do not rely on this time to fix all problems! Test the code early and on multiple machines!
Each team will give a brief (no more than 5 minute) "semi-formal" presentation of the module so far.
- Demos will be given by up to a pair of team members, with different presenter(s) demoing for each integration. By the end of the semester, the whole group will have been part of a presentation.
- The presentation should show of your module and what progress you have made since the last demonstration. Walk us through the main use case, showing us how the thing works as if we were a potential user. Because the code is being run from a central base, your demo should let us see how your module fits into the overall software system.
We will spend the last 10 or 15 minutes of the class session discussing any outstanding issues for the following sprint. Note that the pair giving the demo will be responsible for speaking for the whole team. Do not just defer to another team member; as a presenter make sure you're on top of the development enough to answer any questions and negotiate any priorities!

These demonstrations involve integration between modules, thus teams will need to work to coordinate with one another! Keep in touch with other groups (using email, messaging, GitHub tracking, etc).

Do a "code freeze" a day or two in advance of the demo. At this point you stop adding new code/features, and only change the code-base to fix bugs and make what is there better. Check in with the other groups to make sure their code is up to date (frozen), and then check out their changes and start debugging the integration.
- Use issue tracking to make sure that you don't duplicate bug fixes or that you agree on different solutions!

Specific details about each integration demonstration are below.

Integration 1 - Fri, Nov 1

For the first demo, think of presenting an "alpha" build of the project. Your module's core functionality should be demo-able, though it may lack polish or some major features. Atfer viewing your demo, the viewer should be able to say "Ah-ha! I understand what your system does and believe that it does that thing!"
This demo will also represent the first integration test (and thus is likely to be a little rough). At this point, we're mostly looking to make sure that each module runs within the same system as the others, and there there is a little bit of connective tissue to get from one module to the others. So for this demo, modules need to be collocated, but not necessarily in full communication (but the more communication you can include, the better!)
Post-demo discussions might (but not necessarily) focus on how to enable communication and further integration, so be ready!

Integration 2 - Mon, Nov 25

The second demo should present a "beta" build of the project. At this stage, 85-90% of your module's functionality should be demo-able, though some polish and extras may still be needed.
In terms of integration, at this point each module should be communicating with every other module. The user should be able to do something in one module and see its result used in another. Basically by the end of the demos, the viewer should be able to say "yes, this system will be able to fulfill the requirements".
Post-demo discusions might include what features will need to be included in the final build.

Integration 3 - Wed, Dec 11

The third demo should present a "release candidate" build of the project. 100% of functionality should be demo-able. There may be the occassional bug or a few assets missing, but the project should be mostly completed. This demo should show off the final project, though the final build isn't due until finals week.
As this point, the entire system should be integrated to work smoothly together.
Post-demo discussion might cover last-minute changes, fixes, and deployment decisions.

Although these deliverables are spread out over many weeks, do not wait until the last minute to implement your module! You should be working on the implementation regularly, making consistent progress. If you need more frequent check-ins to help keep you on track, let me know and we can arrange something outside of class.

Submission

Demos will be presented in class on the dates specified. Working code should be committed to the main branch of the project repository before class; the code in this repo will be used for the demonstration!

Grading

Demonstrations will be graded on a "plus-check-minus" system---basically in terms of completion. I will be looking to make sure that:

Your module is demo-able (the build is not broken)
Implementation (including integration) is progressing at a reasonable pace

The presentations and discussions led by each presenter will be graded on an individual basis. You will be graded on how well you can show off and explain your module (particularly in terms of any questions raised during discussion). If you can hold your own and explain what is going on, you'll be fine.