Software Engineering Project Demo

Demo #1 -- Iteration 1(c) --  (date listed here)

1. Demo Format
2. Demo Video Preparation
3. Product Brochure
4. Demo Schedule
5. Effort Breakdown and Grading
6. Demo Documents Submission

The purpose of the demo is to show your progress and receive feedback.

The demo should focus on showing the key features of your software system from the user’s viewpoint. Minimize the spent time on non-essential features of your product, such as login, user authentication, and creating new user accounts, unless you implemented these in a novel, previously unknown way. Create some user accounts before the demo, so you can use the existing accounts to demonstrate the system functionality. Focus on showing the essential functionality of your system. Spending time on non-essential functions leaves the impression that there are no essential functions to show, or disregard for time constraints (20 minutes of presentation time).

The demo format is as follows:

1. Up to five (5) slides for a short overview of the product—who and what it is for, and the roadmap of your presentation
2. Live program demonstration that shows how most important use cases are working:
   Ideally, each use case should be presented by the “product owner” as shown in the Customer Statement of Requirements in Report #1)
   1. Briefly describe what each function/use case does, what business goal it helps to achieve
   2. Demonstrate a scenario of how the users use it
   3. During the demonstration, highlight the important aspects of your solution, such as elements of the user interface design, data processing at the application’s back-end, etc.
3. Brief outline of your plan for the rest of the semester—what new features you are planning to have ready by the final demo.  You may show your product roadmap · maybe already included in your Report #1 (Plan of Work).

Focus on showing how your system solves an actual business problem. If your application uses a database, prepare several example records before the demo and avoid creating new records during the demo. Use your allocated time to show your product rather than create another user profile or manage user accounts.
Similarly, if your system offers different services to different user types (different “initiating actors”), create profiles for different user types before the demo. During the demo, show the services offered to these users.

You want to show that:

• You are addressing an important problem
• The problem presents technical challenges, which you successfully solved
• Your solution employs high-quality software design
• This system will work reliably, and be easy to understand and use

Because of time constraints, it is helpful to use a “roadmap slide” to orient the audience and let them know what is coming next.  Interesting to consider:  Harvard Researchers: Prezi is More Engaging, Persuasive, and Effective Than PowerPoint.
Avoid showing source code, because there is no time to present the whole program and it is not possible to understand short segments code out of context and under time pressure.  Instead of showing how the code works, explain what it does by using diagrams and animation.
When showing a table with data, or a chart, tell the audience what they are supposed to see in your data or charts—what are the key points they should see.  All charts should show the labels and units on the axes.

Each student team will create a single video for their project that presents all sub-projects combined and post it on YouTube..
The video duration for each team should not exceed 20 minutes.
See information about video preparation here:

• wikiHow: https://www.wikihow.com/Upload-a-Video-to-YouTube
• YouTube: https://www.youtube.com/watch?v=IYKLBER-zqM

Here are the steps for the demo video presentation:

1. Each team will prepare a single 20-minute video and upload the video on YouTube no later than two (2) days before the scheduled demo date, by 11:59 PM.
2. When you upload, email the link to the instructor and the TA/graders.
   Include in your email the YouTube link to your video, your product brochure, and your PowerPoint slides.
3. The instructor and the TA/graders will view the video, prepare a list of questions for each team.
4. During each scheduled demo slot, we will use Zoom or WebEx to have a 10-to-15-minute question-answering session with each student team.
   (We will use the video conferencing service that we are using for our regular class meetings.)
   The Q/A session will be followed by a 15-minute private discussion about each project during which students will be asked to leave the meeting.
5. Students will be asked to join a Zoom or Webex session during their already scheduled time slot as published on Google Docs (to be shared with the class separately).
6. Soon after the demo we will email to all teams our feedback and suggestions on how to improve their project. Our feedback will mostly list the questions that we asked during the Q/A session, and point to the issues that were not clear in your video and could be improved in the next demo or report.

Each team should bring to the demo a one-to-two-pages advertising leaflet providing basic descriptive information about their software product and distribute to the instructor and the TA/graders.  No more than two (2) pages are needed. At the least, the brochure should include the demo date, group number and members’ names, project title, project webpage URL (e.g., on GitHub), the list of features and short description of each feature, system requirements to run the system, etc. A block diagram of the system and some screen snapshots could be useful, too. This should be more of a marketing brochure rather than a technical document.

The Demo Room is specified here.  There will be no class during the demo week.

The demo should last not exceed the allocated time slot (usually 30 minutes), which includes the setup and cleanup times. Rehearse your presentation before the actual demo. The schedule is tight and it is unfair to the groups that follow your presentation if your delay upsets their schedule.
Students are required to test the network or projector connectivity for their computers before the actual demo. See the TA before the demo if you need help with network or projector connectivity in the demo room.

Plan well in advance, so you can avoid disaster scenarios:

• You’re programming the night before the demo and a team member accidentally overwrites the latest code with an old version.
• Everything is running fine on your personal computer, but you never tried it on the computer that will be used for the demo, so the demo fails.
• The computer used for the demo does not have a display port compatible with the data projector in the demo room, so during the demo you must urgently search video-convertor cables.
• A key team member, the only one who knows how a particular module works, cannot make it to the demo and others do not know how to run this module. Every team member must be familiar with the system so to be able to conduct the demo on their own (and answer questions).

4.1   Demo Attendance

All team members are required to be present for their demo. It is not required that each member take part in the demo. However, you must email us your individual contributions breakdown to facilitate fair grading.
If someone cannot make the demo, they should provide doctor’s notice or other justified reason for absence, such as overlapping lecture or exam. The student who will miss the demo must beforehand ensure that other teammates are familiar with his or her part of the project—they should be able to demonstrate it and answer questions during the presentation.

All students are encouraged to attend other groups demo so they can see how other students present their work and how their progress compares to the rest of the class.

See also the grading policy for the assigning the overall team grade vs. grades for the individual members.

5.1   Grading of Project Demos

All demos will be graded based on the following aspects that are visible from the demo presentation:

• Integration of project parts into the whole system:  are the parts of the system implemented and integrated together, instead of just being described hypothetically in slides or working in isolation from one another;
  this includes database integration, if applicable
• Clarity of the presentation of the system functionality as seen from the user’s viewpoint  (includes the slides quality)
• Highlighting of the select few most important functions instead of getting lost in many minor details
• System is using data instead of just moving data (from user interface to database and back):
  i.e., based on understanding of the user’s problem, the system extracts information from input data and uses this information to suggest the user how better to achieve their business goals
• User interface that is easy to understand and navigate
• Explicit highlighting of novel contributions:
  if a similar system was developed previously in this course or exists in the market, the presentation should make clear how their work is different
• Teamwork at display:  it is clear that the presentation that the system is the result of teamwork, not just one or few students
  Ideally, each use case should be presented by the “product owner” as shown in the Customer Statement of Requirements in Report #1)
• Debugging, as reflected in program running without crashing

In addition to the above-listed visible aspects, during the grading we will consider the following criteria that are not visible directly from the presentation and will be determined from the submitted demo materials (see Section 5 below):

• Coding quality
• Unit testing design and implementation
• Program documentation
• Data collection, either from real world or synthetically generated data
• Project brochure
• Project management

Each project will be assigned a single score on the scale 0 - 10 points.
For design-type problems, there are many possible solutions, and each type of solution can be worked to a different degree without ever being complete. Because solutions are neither unique nor closed, they cannot be graded on an absolute scale. Therefore, when assigning the project grades we will use a relative scale and compare projects to each other, in the context of the whole class.

The projects will be scored as follows:
The graders, TA, and the instructor will meet after the demo and review all aspects of each demo, as listed in the above two lists of criteria. We will put everything in the context of all demos that we have seen.
We will not quantify every single issue and instead we will reach a consensus rank-ordering of all projects by pairwise comparison of every two projects.
Based on this rank-ordering, we will assign an aggregate point-score for each demo on the scale of 1 - 10 points.
The emphasis will be on reaching a consensus for every issue through several iterations and discussions, to minimize subjective errors of each participant.
The next step is assigning individual student grades, based on their project score, as follows.

The simplest approach is to report “equal contribution” for all team members.
Alternatively, each team member can report different contribution percentage to their project, and the percentage contributions must add up to 100%.
If reporting your individual contribution, consider the following items:

1. program code writing—list explicitly which use cases or user interface screens were programmed by individual team members
   (this list should correspond to the “product ownership” that was stated in the Customer Statement of Requirements in Report #1)
2. unit testing^‡ (includes writing the program code to run unit tests and analyzing their coverage) and integration testing^‡ —breakdown by individual team members, applies to all remaining items
3. front-end design (HTML, CSS, JavaScript, XML, if applicable)
4. integration and integration testing, cross-platform issues, if you are developing for desktop and smartphone^‡
5. testing algorithms that implement mathematical models, non-functional requirements, or user interface requirements stated in your Report #1^‡
6. debugging
7. program documentation, including code comments, technical documentation, user documentation, etc…^‡
8. designing database tables and maintaining the database (if applicable)
9. data collection (if applicable)^‡
   • writing scripts or programs for data collection (if applicable)^‡
   • Other: _____________________
10. brochure/flyer preparation—informativeness and general appearance of the product brochure
11. slides preparation—informativeness and general appearance of the slides
12. project management, including
    • opening accounts on public websites for the project
    • organizing meetings
    • coordinating activities
    • system evaluation with external users (if applicable)
    • installing and maintaining the developer’s resources
    (IDE, relational database, Web server, public archive, version control, ...)
    • combining all of the contributions into the correct files and formats
    • Other: _____________________ (include everything that you believe contributed towards making your demo successful)

Individual student grades will be calculated from the project grade as detailed here.  (Also see the description here.)

Using a file sharing website, share the folders as below. If any item is not applicable to your project, state and explain in individual_contributions.pdf below. Also propose how the points from non-applicable items should be allocated to other items.

The main folder should contain the following subfolders (see more details about each item above):

1. 1_code
   includes all your code with comments and README1.txt on how to run the code (see about README on Wikipedia)
2. 2_unit_testing
   program code to run unit tests and README2.txt on how to run the unit tests
3. 3_integration_testing
   program code to run unit tests and README3.txt on how to run the integration tests
4. 4_data_collection
   scripts or programs for data collection and README4.txt on how to run the data collection scripts
5. 5_documentation
   includes the following 5 separate documents with cover page indicating what document it is, project title, group number, group members. Include the table of contents wherever appropriate (PDF only!):
   1. technical_documentation.pdf
   2. user_documentation.pdf
   3. brochure/flyer.pdf
   4. presentation_slides.pdf     (acceptable formats: .pdf or .ppt)
   5. individual_contributions.pdf     (this document should include the project management information, item 12 in Section 4.1 of this webpage)

Upload your files on a file sharing website such as GitHub or Dropbox because sometimes the mail server removes code file attachments. Make them public, so that we should not need to login to access your files or search for them.

Submission deadline: The documentation for the demo is due no later than two (2) days after the demo presentation date.

• Course home page
• Course syllabus page