SEG4110 UML Design Assignment and Course project - Fall 2011

The following are the two major deliverable work items for the Fall 2011 version of the SEG4110 course. Please see the course syllabus for additional details of marking. In addition, the TA will give you further guidance. Note that there are additional smaller work items you must submit from the various labs.

Course Project for SEG4110 Fall 2015

The following are the components of the SEG4110 course project you will need to work on.

Your task is to learn a technology you don't know, to build some software that exercises key features of this technology and then demonstrate it to the class. You also have to get another class member to test your work. The topic can be a language, framework or component technology.

Clearance for the topic .

First, request approval of your topic by email to the professor. Remember the topic is first-come-first served..

Initial version (5%) - Due Nov 15 at 5 p.m..

Send your demonstration to the professor and to another student (we will arrange in class, but not the one testing yours).

There will be absolutely no lateness allowed.

If you can't get your project to work as nicely as you would have liked, then at least do your best given the time available. Cut features and simplify. Focus on quality. Above all, make sure what you have installs and runs for the other team to be able to do testing. Test it yourselves thoroughly before submission.

Here is what is expected: You are going to be providing a version of your work that can be tested by the tester; the tester will need to install your work, and figure out how to run it. Their job for the "Testing report of another group's work." (see below) due about a week later will be to try to find as many problems with your work as possible. You therefore need to address the assignment to the tester as well as to the prof. Give the tester as much information as possible about what it does and how to use it.

The material you hand in will include:

• The source code set up in such a way that it can easily be installed. In general it should be possible to simply unzip the material, run an install script and then start testing. However, you may need to specify other aspects of the environment. When we arrange who will be your tester, we will need to ensure they have the right platform.

  Make installation very easy and obvious or else you will lose marks and the tester will waste time, so they won't have much time to actually test your work. .

• Instructions for using the work (including how to install).

• A set of test cases. You should include as many test cases as you can think of. If possible most of the test cases should be automated (i.e. code to run with expected results, e.g. using JUnit and Ant). The testing team will run these test cases, as well as whatever other tests they can think of.

  Your manual can be as short as you want, but must have enough information to allow the tester to quickly test it.

To hand in your work, put everything into a zip file..

Your mark will be based on the effort you have put into the project, the quality of the testcases and the quality of the instructions for using it. Only 40% of your mark will be on the quality of the system itelf, since you will be marked again on that later when you submit your final report.

Testing report of another group's work (4%), Due Nov 22.

You will be testing another person's work as described above.

If the originator did not submit their 'Initial Report' (and hence got zero), then we will have to make last minute rearrangements of who tests what.

Your job for the testing report is to provide a thorough test of the work you are testing by the deadline. You will send your results back to the originator and the prof. Missing the deadline will result in zero ... no exceptions and no extensions possible.

If you can't get the system you are given to work (e.g. installation doesn't work or it always crashes on almost all testcases) , you are allowed to communicate to the originator. But do not communicate with them in other cases -- just write a problem report (see below).

Problem reports

Your report should consist of a series of problem reports. Each problem report should be as follows:

• One-line description of the problem
• Severity (1=critical failure; 2=important; 3=merely a suggestion)
• Description of what you did, or the testcase number.
• Description of what happened, or your suggestion for a fix or improvement.

In addition, include a cover page describing the overall experience doing this testing.

Feel free to suggest any improvements you can think of. Howver, don't suggest enhancements that would obviously require an excessive amount of work.

You will be marked based on the effort you applied into testing and the quality of your recommendations. If you are given a particularly bad project to test, you will be expected to report primarily severity 1 and 2 problems, since you will not have time to get to the severity 3 problems. Overall, I would expect you to spend an hour setting up and familiarizing yourself with the system and about 3-4 hours on the testing and report writing.

Presentations of systems (8%)

These will be held in the last two classes:

Guidelines for the presentations

You should give a presentation about your project and a demonstration of your system at work. Normally the demonstration should be live. However, remember that you will not have much time to set up. You can do the demo on the classroom computer; if so you will have 2 minutes to install anything you need before class (you must come early). Alternatively you may demo using a laptop that you plug in to the overhead projector. If you have special requirements, e.g. complicated setup, multiple computers, special hardware, etc., then you may create a video of your demo that you explain live. However, please email the professor and the TA for personal permission to do this.

The presentation, including the demonstration, should take no more than 30 minutes and should show off interesting aspects of your work.

For the presentation component, you should spend about 13 minutes explaining lessons you learned from your work that you think the class, the professor and the TA would benefit from knowing. Prepare 4-5 powerpoint slides. The presentation should in general come after the demonstration, although you may need to show one slide before the demo to explain the context.,

Any text on your slides should be at least 20 point font; text of code can be 16 point font or larger.

Make sure you do not duplicate material the professor presented in class or the TA presented in the labs (you will lose marks if you do), so please check with the course notes first. Some of the things you might talk about briefly include:

• Aspects of the technology you think should be taught, but which we did not cover (you could show architectural diagrams, or snippets of code that you will explain line by line, but don't show large amounts of code or text).

• An overview of how your application works, so others can learn from your experience building it. I suggest doing this through diagrams that you explain.

• Things that you found particularly difficult about using the technology. These might be things you had trouble understanding, or bugs you had trouble debugging. You could express this as warnings to others, lessons learned or 'war stories'.

• Things you found particularly 'cool' or interesting that make the technology attractive for you.

• You should conclude by saying whether you would choose to use the same technologies again and what you might do differently.

You should leave about 2 minutes at the end for questions.

I will be very strict cutting you off if you exceed your time budget for your demo.

Here is the marking scheme.

• 40% demo
  • 10% Does it work well
  • 10% Does it do something interesting /educational for students
  • 10% Does it show you have paid attention to quality
  • 10% Does it make appropriate use of the technology
• 60% presentation on sessons learned
  • 40% Educational value for the other students (duplicating what we learned in class will detract from this)
    • overview of how it works (diagrams)
    • things you found difficult / war stories
    • things you found 'cool' or interesting
    • what you would do differently in future
  • 20% Quality of the slides (large font, short points, etc.).

As a reminder: Come early to set up. It would be best if most groups have everything on a laptop. If you bring materials to class, and expect to install them before class, I strongly suggest you use a 'memory stick'.

Don't panic if your demo crashes. Do your best. I will be lenient, especially for the first group.

Final report (10%)

Due: Dec 9 at 7 p.m.

Here are the deliverables

• Your code, properly commented. You will be marked on style and general code quality. Embed enough comments to make the code understandable.

• A cover letter explaining the changes you have made since you submitted the original system for testing.

Last update to this page: Friday, 30-Oct-2015 15:52:09 EDT