Project Hand in Details

How to Submit

Email me at Leif.Azzopardi@glasgow.ac.uk a pdf of your report and a zip of your code.

If your code is larger than 10mb, consider emailing me a link to the zip file that contains your code and data.

The subject of the email should be SUBJECT CODE: TEAM NAME - APPLICATION NAME.

For example, ITECH: Team X - Bandits for Hire.

Demo

You will need to demo your application either on the 12th (DIM3) or the 13th (ITECH) of March in the labs.

• Attendance is compulsory

• Arrive early and setup

• Have your application up and running on two machines.

• Run your application with the IP address of the lab machine and port 8000. This is so it is accessible to other machines.

  • Get your IP address from: http://whatismyipaddress.com

• Staff members and folk from industry will come to your group to check out your demo.

  • You will need to be ready for them

• During the demo we will be looking at:

  • [VISION] How well you have explained the aims of the application

  • [USER EXPERIENCE] The look and feel of your application and how it handles

  • [COMPLETENESS] Whether it is functional and lets users achieve the main application objectives.

    • i.e. if the applications is lets people make bets, then users should be able to make bets, manage bets, take bets, keep tally of the bets, etc.
    • if the application collects code snippets, then users should be able to upload code, find code, browse through the code repo, comment on code, etc.
    • if the application is a MOT booking system, then users should be able to make a booking, update their booking, cancel a booking, find a time slot, etc.

  • [MASTERY] Mastery of web technologies - the inclusion of css toolkits/javascripting/jquery/ajax/processing data from external services (i.e processing json/xml/etc) to achieve non-trivial functionality i.e. if you have shown that you have used this technology to do achieve something useful

    • For example, adding in AJAX to post a form without a page reload is useful and functional, whereas adding in some JQuery to show/hide some div of text is not particularly useful (but may add to the look and feel of the application).

  • [DIFFICULTY] Complexity and difficulty of the application. We will be looking at how hard/easy the web application would be to develop.

• No demo should show off how users can login.. that was covered in the tutorial and is not specific your application.

  • You need to show off what is the novel and interesting about your application.

• Have credible and realistic data in your database.

  • Also, if I accidentally delete your database make sure it can be restored.

• During the first hour or so of the lab, we will assess each application. Then we will choose the best ones which will be asked to present to the audience via a machine connected to a projector.

  • Note the project resolution is likely to be 800x600, but may be higher, so you’ll want to make sure that your CSS is responsive to handle different resolutions.

Report

• Make sure that you complete all the sections in the report and that your include references or urls to the technologies used.

• In the template I have asked a number of questions, not all of these need to be answered. Some are reflective questions, which I have included because this is the type of stuff you SHOULD be thinking about when designing an application.

• Ensure that you have included a clear N-TIER architecture diagram (which is labelled appropriately and with technology specified)

• Use a Compressed Chen notation for your ER diagram.

• Include 2-4 screen shots (or wireframe) which are annotated and that facilitate a walkthrough of the application (one screenshot/wireframe should be the main page)

• Include 2-3 sequence diagrams. One should show the main page (unless it is completely trivial) and the associated interactions, and another should show the interactions of the other screen shots.

  • Make sure all interactions are numbered/labeled and they specify the request/response, the protocol used, the request details, the payload/format

• Again the screen shots and sequence diagrams should show NON-TRIVIAL functionality and interactions.

  • i.e. for example the aggregation of data from a number of sources such as multiple database queries or when a number of queries to external services are made.

• Make sure you have added in an accurate functionality list of what works and what doesn’t

• Ensure that you have added in who was responsible for what and percentages of effort.

  • i.e. Joe did the database, Jan did the middleware and Jon did the front end. All work was completed equally.
  • or, Joe did fall, Jan did the d/b and middleware and Jon did the front end and report. Jan (50%) and Jon (50%).
  • If there are any disputes arrange to see me.

Code

• Hand in:

  • Include a README file that includes:

    • all the python packages required for your application to work
    • any other configuration details
    • links to your sourceforge/github/googlecode repository
    • and instructions on how to run it.
    • Include a population script for your application (in case the db is corrupted/deleted, etc)

  • A zip file containing all the relevant code for your project

• I need to be able to run your code (with minimal fuss) the more intervention I need to do to assess your code less you will get for it.

• As a minimum your project should:

  • provide the main functionality associated with your application

    • i.e. for the MOT booking application, I should be able to book an appointment, view appointments, cancel, find a slot, etc.
    • for the Betting app, I should be able to make a bet, take a bet, etc.

  • at least 5 NON-TRIVAL views should be implemented. i.e views that make calls to the database and/or external services to provide this functionality.

    • Login and Registration views do not count.
    • A few projects may require more backend processing in which case I will take this into account, for instance one Application takes playlists and maps them to a locations on a google map (which will requires more back end and frontend work).
    • If you believe you will not have atleast five non-trivial views then check with me.

  • show at least a basic demonstration of CSS and thus have css files included

  • show at least some trivial use of javascript/jquery i.e. used to manipulate the interface in some way

  • use XHTML and be a valid XML document

Marking Scheme

The project, presentations and code will be marked out of 22 bands:

• Five bands will come from the demonstration and based on the scores given by judges on the five criteria provided.

• Three bands will come from the pitch and based on how well you communicated the aims and objectives of your application, the quality of the wireframes, etc.

• Six bands will come from the quality and presentation of each of the main elements: aims/objectives, n-tier architecture, ER diagram, sequence diagrams, implementation notes and functionality list, summary of technologies, etc.

  • You will lose bands for poorly presented diagram, poorly or inadequately explained diagrams, if there are any errors within your diagrams, etc.
  • You will lose bands for not completing each section

• Six bands will come from the code and the functionality provided.

  • Code must work and run as per the functionality list, else you will lose bands.

  • Variables names, Function names etc should be sensible and clear - so that when I read through your code it is clear what it means.

    • i.e. def x(request): BAD, def post_msg_to_forum(request): GOOD
    • x = .... BAD, user_id = ... GOOD

  • URL Mappings and GET requests should be sensible and intuitive.

  • Any redundancy in the code should be avoided so similar code between views should not be repeated (this goes for code in views and templates).

    i.e. you will lose marks for doing this

  • If you steal my code from the tutorial have the decency to change the name of the project, the application, etc. Otherwise, you will lose bands. You need to make your own project/application.

  • Acknowledge the use of any third party libraries, django apps, etc that you use.

    • THIS SHOULD BE NOTED IN THE README file.

• Two bands will come from the quality of the report in terms of syntax and style, etc. You will lose bands for a lack of clarity, poor exposition, excessive spelling and grammatical errors, poorly formatted

• BONUS Bands: Sometimes it is not possible to tick all the boxes on everything. So bonus bands will be awarded if your team excels in some respect, i.e. gives an awesome demo, produces an excellent application or writes a very good report.

  • Up to 3 bonus bands, will be awarded which will offset any losses in other areas. i.e. your team can score a maximum of 22 bands out of 22.

  • So for example, if the demo does not go very well, but when I inspect the code and it shows a high standard of workmanship and goes beyond the minimum required then I will consider giving bonus bands based on the code component.

  • This is to ensure fairness across projects i.e. those teams that do more will have provided more to assess and will be rewarded for that.

  • Also, depending on the DIFFICULTY of your project as rated at the demo, your team may receive a bonus band - this is to ensure that teams that undertook very difficult projects are not penalized for trying to be innovative/cool/novel/etc.

  • NOT FOLLOWING ANY OF THE CRITERIA SPECIFIED HERE WILL RESULT IN THE LOSE OF ONE OR MORE BANDS FOR EACH VIOLATION.

  • Also note that if the code does not reflect the design report you will lose up to three bands for each discrepancy.

    • For example, if the model says there is a one to many relationship between A and B, or that A contains the fields X Y and Z, but when I inspect the code the relationship is a many to many or some of the fields are not there, then this is a discrepancy that will be penalized.

Deadline

DIM3:

• The deadline shown on moodle is a soft deadline.
• However, I will not be imposing any late penalties on reports or code, until 11.59pm on 12th of March.
• So in practice you have up until the 11.59pm on the 12th to submit your report and code to me.
• Late penalties will be imposed from the 13th of March.

ITECH:

• The report and code is due on the 15th of March by 11.59pm.