Software Engineering - Project Demo #1

Demo #1 -- Iteration 1

1. Demo Format
2. Demo Video Preparation
3. Demo Schedule
4. Demo Grading
5. 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. An allowable number of five (5) to at most eight (8) presentation slides for a short overview of the software 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. You may show and explain source code, but avoid dwelling on it too much - 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. 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=w25FNPlnXXQ

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 before the scheduled demo due date, by 11:59 PM (Central Time).
2. Upload the link to the Blackboard discussion board. A discussion board has already been created. Kindly create a new thread for your project group's demo YouTube link submission.

The demo schedule will be communicated to all students via Blackboard  There will be no class during the demo week.

The demo should not exceed the allocated time slot (usually 20 minutes). 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.

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).

3.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.

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 management

Submit your demo documents via Blackboard submission portal - provided in the course shell. The file/directory submission format is presented below:

The main folder should contain the following subfolders:

1. code
   includes all your code with comments and README1.txt on how to run the code (see about README on Wikipedia)
2. unit_testing
   program code to run unit tests and README2.txt on how to run the unit tests
3. integration_testing
   program code to run unit tests and README3.txt on how to run the integration tests
4. data_collection
   scripts or programs for data collection and README4.txt on how to run the data collection scripts
5. documentation
   includes the following 4 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     (of use case diagram, sequence diagram, class or domain diagram, database schema, etc.)
   2. user_documentation.pdf     (that is, user manual or "walk-through" on how to run the software program and navigate the user interfaces)
   3. presentation_slides.pdf     (acceptable formats: .pdf or .ppt)
   4. individual_contributions.pdf     (this document should include the project management information)

Submission deadline: The documentation submission for the demo will be communicated on Blackboard.

• Course project home page
• Mike Mireku Kwakye's home page