Course:COMP1309 Coursework Number: Contribution:

Web Engineering 1 of 1 50% of course

Greenwich Coordinator: Due: 13/04/2010
Mr Dimitrios Frangiskatos
This coursework should take an average student who is up-to-date with tutorial
work approximately 50 hours
Learning Outcomes:
A, C, E

Plagiarism is presenting somebody else’s work as your own. It

includes: copying information directly from the Web or books
without referencing the material; submitting joint coursework as an
individual effort; copying another student’s coursework; stealing or
buying coursework from someone else and submitting it as your
own work. Suspected plagiarism will be investigated and if found to
have occurred will be dealt with according to the procedures set
down by the University.

All material copied or amended from any source (e.g. internet,

books) must be placed in quotation marks and in italics, with a
full reference to the source directly underneath the material.

Your work will be submitted for electronic plagiarism checking.

Any attempt to bypass our plagiarism detection systems will be
treated as a severe Assessment Offence.

Coursework Submission Requirements

• An electronic copy of your work for this coursework should be fully uploaded
by midnight (local time) on the Deadline Date.
• The last version you upload will be the one that is marked.
• For this coursework you must submit a single Acrobat PDF document. In
general, any text in the document must not be an image (ie must not scanned)
and would normally be generated from other documents (eg MS Office 2007
using "Save As .. PDF").
• For this coursework you must also upload a single ZIP file containing
supporting evidence.
• There are limits on the file size.
• Make sure that any files you upload are virus-free and not protected by a
password otherwise they will be treated as null submissions.
• Comments on your work will be available from the Coursework page on the
Intranet. The grade will be made available in BannerWeb.

By D.F Page 1 01/02/2010

 • You must NOT submit a paper copy of this coursework.
Coursework Regulations
1. If no submissions were made before the deadline, coursework submitted up to
two weeks late that meets the criteria for a pass will be treated as a referral. It
will be subject to university regulations for referral work.

2. Coursework submitted late without an Extenuating Circumstances claim will

receive a ZERO grade.
If you have extenuating circumstances you may submit your coursework up to
two weeks after the published deadline without penalty but this is subject to
acceptance of your claim by the School Extenuating Circumstances Panel. If
your claim is rejected then you will receive a zero grade for your work.

3. Coursework submitted more than two weeks late will be given feedback but a
grade of non-submission will be awarded regardless of any extenuating
circumstances. However, if your Extenuating Circumstances claim is accepted
then the Extenuating Circumstances Panel will recommend to the Progression
and Award Board that you be permitted to retake a different item of
assessment at a future assessment point.

4. All courseworks must be submitted as above.

By D.F Page 2 01/02/2010

Detailed Specification
This coursework must be completed individually.

You are to create an adult education web site. Visitors to the site will be able to
register as members and store personal information, images and upload their
assignments. Once they are registered they should be able to access learning material.

To implement the site you should adhere to the following specification:

• Use Valid XHTML 1.1,
• Use Valid CSS,
• Use JavaScript for the client-side coding,
• Use PHP for the server side coding,
• Use the UNIX Apache web server (Server Details section),
• Use the UNIX MySQL database server (Server Details section).
Note: you will be required to design – use an ERD - and implement the database
yourselves!
Additionally:
• Your web pages should give serious consideration to usability, and how CSS
and JavaScript can be used to enhance this,
• Your web pages must display and operate correctly on all popular web
browsers, i.e. Mozilla, Microsoft Internet Explorer, Opera, Firefox, etc.
• Client side (JavaScript) and server side (PHP) scripts should be used to
validate input data from all forms.

You are required to produce a web site that passes W3C XHTML 1.1 validation
using http://validator.w3.org

Your web site must pass at least the Priority 1 W3C web content accessibility
guidelines (using Bobby™ or WebXACT™).

Remember:
The site must run from the UNIX Apache web server stuweb.cms.gre.ac.uk and the
UNIX MySQL database server studb.cms.gre.ac.uk provided by the school.
DO NOT USE ANY LOCAL SERVERS

A few hints on how to start: First decide what information you need to capture in the
database and group/organise it accordingly. This is a critical task and you need to do
this before attempting any kind of database implementation. Then design the ERD
model of your database and the storyboard of the required web pages. Try to adhere to
the rule “simple is better” as this will allow a trouble free validation of your web
pages. Then try to identify what you can put in the CSS. Once that is done you can
implement the database and the required web pages and test that information can be
exchanged through the web pages with the database.

Functionality to be achieved
This is expressed as a number of levels. The level of functionality implemented in
your application will determine the maximum possible mark that you can achieve.

By D.F Page 3 01/02/2010

The actual mark awarded depends on the quality of your work. Make sure that you
fully understand the grading criteria.

It is recommended that in designing your websites (and databases) you should allow
for all of the features to be implemented. In building the websites each level should be
attempted in increasing order. Starting with Level 1 you should incrementally enhance
your work to include the next level.

Level 1: Account creation

Create an XHTML form which allows visitors to create an account with the site. The
form must mandate basic contact details but should also allow for personal
information to be included. Account details are to be stored in your MySQL database.

Visitors should be able to choose a username and password. The system must prevent
duplicate usernames being chosen. Newly created accounts should remain inactive
until they are verified by handshaking the email details (Level 3). Members may wish
to conceal their email address from other members to avoid spam.

Note: Remember that some characters (notably the apostrophe) can cause
problems with SQL strings. The staff passwords should ideally be stored in the
database in an encrypted format. Authentication credentials should be protected
from interception in transit.

Level 2: Authentication
Provide a login form that allows members to authenticate with the site using their
username and password. These credentials should be compared with the
information recorded in the database.

Note that you will need to initiate some form of session state to prevent unauthorised
access to further activity. New members will also need to verify their account details
(Level 3) before being allowed access to further activity with the site.

Level 3: Verify account

Account verification will require sending a message to the email address provided in
level 1. This email message should include some sort of key that enables a member to
activate their newly created account after they have authenticated with the site.
Members should not be allowed to make further use of the site (e.g. access learning
material) until they have verified their account.

Note: This page must include PHP that denies access to users who have not
authenticated as a member using the form that you created in Level 2. Members
should only be required to verify their account the first time that they authenticate.

Level 4: Editing details

Provide XHTML forms that allow authenticated members (who have verified their
account) to add to and edit existing information stored about themselves. You should
provide a tiered information store with some information being visible to all other
members, some information visible to other members who are classmates and some
information that is private (not visible to any other members).

By D.F Page 4 01/02/2010

Note: Editing information is not the same as re-entering information, the user may
only be seeking to correct a spelling mistake and so should not be required to re-enter
complete data. The simplest way to implement this is to re-use the form that you
created in Level 1 but populated with default values extracted from your database.

Level 5: Image upload

Provide XHTML forms that allow authenticated members to upload their images. The
system should allow multiple images to be stored with a means of deleting stored
images. At least one image of each adult learner should be displayed in his/her profile
next to his/her details.

Note: Images may be stored as either files on the server or as records in the MySQL
database.

Level 6: Personalisation
Provide a means for members to be able to personalise the way in which their
information is shown in a browser. This may include choice of colours, font faces,
font sizes and so on.

Note: This could be implemented in a number of different ways. You could simply
alter the CSS or you could allow members to include markup in their stored
information.

Level 7: Member search

Create a means by which learners can search the public information of their
classmates and the various courses (e.g. course specifications). Search results should
be formatted as a list in which each entry in the list may be clicked to show the
complete public profile of the other member (e.g. courses that they attend).

Level 8: Report
A report (contents page, introduction, problem analysis, design considerations,
discussion, conclusion, references) describing your work as detailed in the following
section under ‘Deliverables’. This report should contain sufficient information to
allow another developer to understand and maintain your work. Your references
should adhere to the Harvard referencing system and they cannot be in the form of
“www.google.com” or “www.wikipedia.org”. Marks will be deducted for bad
references and poor report structure and content (including grammatical mistakes).
You MUST produce a report no matter what level of functionality you have achieved.

The main body of your report should be no less than five pages long and no more
than nine pages long (without the references or the appendix).
YOU MUST NOT PUT THE XHTML/CSS CODE, STORYBOARDS,
SITEMAPS, DESIGN DIAGRAMS, ERDS, TESTING PLANS IN THE MAIN
REPORT. PUT THESE IN THE APPENDIX.

By D.F Page 5 01/02/2010

Use of tools
You are expected to use web authoring tools such as EditPlus, Bluefish and XMLspy
to aid your productivity. If you wish, you may make use of WYSIWYG tools such as
Dreamweaver or Visual Studio.
Be careful when using code generators that you don’t modify the code that is
being generated. If you use a tool such

By D.F Page 6 01/02/2010

 B. A report consisting of:
• A completed self assessment sheet (see end of this document),
• contents page,
• introduction,
• problem analysis,
• design considerations,
• discussion,
• conclusion,
• references (adhering to the Harvard referencing system),
• appendix (you will have to put the code for the entire website there)

In the main section of your report (discussion) you need to have at least the
following:

1. A statement of the functionality that you have achieved as described in the

specification. If you have not achieved all of a certain level then specify the
sub-parts of it e.g. all of level 1, 2 and 3 plus some of level 4.
2. A list of any bugs in your program (if you don't think there are any then say
so!). Bugs that are declared in this list will lose you fewer marks than ones
that you don't declare!
3. A brief (up to 1000 words) reflection on the strengths and weaknesses of your
program. This is your opportunity to show the tutor what you have achieved,
why you have done things in a particular way and what you have learned from
the process.

Your report should contain sufficient information to allow another developer to

understand and maintain your work. Your references should adhere to the Harvard
referencing system and they cannot be in the form of “www.google.com” or
“www.wikipedia.org”. Marks will be deducted for bad references and poor report
structure and content (including grammar mistakes).

The main body of your report should be no less than five pages long and no more
than nine pages long (without the references or the appendix).

YOU MUST NOT PUT THE XHTML/CSS CODE, STORYBOARDS,

SCREENSHOTS, DESIGN DIAGRAMS, ERDS, TESTING PLANS IN THE
MAIN REPORT BUT IN THE APPENDIX.

Server Details

To upload your website to the server you need to use an FTP client such as:
• Filezilla – free to download and use
• WinSCP – http://unix.cms.gre.ac.uk/software/mswindows.html#winscp,
and FTP the files to stuftp.cms.gre.ac.uk. The login name (userid) and password -
which will be unique for each one of you and must be kept secret- will be printed on

By D.F Page 7 01/02/2010

your registration form (sent to your centre by the University when your registration is
complete).

Once you upload all of your website files (remember that your website must be placed
in the public_html directory and that you don’t have to create it yourselves as this
directory is already there) you need to make sure that you have set the correct
permissions to access it from the Internet. These permissions are readable and
executable for the owner, group and everyone else. To set/change permissions of
directories and files in UNIX you use the chmod command and for that you need to
telnet to the UNIX server student.cms.gre.ac.uk (again the login name and password
will be provided by your centre). To telnet to the server it is recommended to use
putty which can be found at
http://unix.cms.gre.ac.uk/software/mswindows.html#putty.
The advantage of using putty over traditional telnet when connecting to the server is
that userid and password are encrypted.

In your PHP code you will need to use studb.cms.gre.ac.uk in the connection string
to achieve connectivity with the database server. Before you do that though, you will
have to create the database tables and relationships on the server. There are two ways
of creating a database: manually using the command line from within UNIX, or by
using the web interface. To use the command line you will have to telnet onto the
UNIX server student.cms.gre.ac.uk (again the login name and password will be
provided by your centre). Assuming that your username is ab001 you will need to
type mysql -h studb.cms.gre.ac.uk -u ab001 -p mdb_ab001 to connect to the
MYSQL server.
To use the web interface to create your database (this is easier!) visit
https://stumyadmin.cms.gre.ac.uk
(again the login name and password will be provided by your centre).

For more help, and connection code examples visit

http://unix.cms.gre.ac.uk/
and then look on the left of the page under “Quick Links” for “MySQL help”, “PHP
and MySQL help” and “code examples”.
To view and test your webpage, assuming that your username is ab001 and that you
have a file named index.html in the public_html directory containing the first page
of your website, you will need to go to the following URL:
http://stuweb.cms.gre.ac.uk/~ab001/index.html.

Visit http://unix.cms.gre.ac.uk/ if you have any other problems/queries not

addressed here.

Grading Criteria

The specification is given as eight levels. Levels 1 -7 worth an equal proportion of

the marks (12%). Level 8, the report, is worth 16%.

By D.F Page 8 01/02/2010

Your tutor is there to guide you in completing your coursework but not to implement
it for you. You should seek regular feedback from your tutor to ensure that you are
progressing in the correct direction at the correct speed.

Assessment Criteria
• Have you achieved all the required functionality, or only some?
• How well have you achieved the functionality?
• Have you incorporated any features that were not explicitly included in the
requirements, but which add value to the site?
• Is the application easy to use? Is it obvious to the user at each stage what he/she
needs to do next?
• Are all messages to the user clear and unambiguous? Is the layout consistent,
attractive and easy to read?
• Is navigation though the application clear and straightforward?
• Does the application follow WAI accessibility guidelines?
• Is your application reliable? For example, if it crashes every time the user enters
invalid input you will lose marks. Faults that you admit to on your bug list (see
deliverables) will be looked on more sympathetically than those that are not
declared.
• Is your code of high quality? For example: inclusion of meaningful comments, use
of sensible naming standards (e.g. for variables, functions and files) and code
layout (e.g. indentation to make the structure clear).
• How many of your pages pass W3C XHTML validation?
• Does your application operate correctly on all required browsers? If any features fail
on a particular browser, does it fail gracefully, or simply crash?
• Have you used technologies in an appropriate manner? For example, is user data
validated on both the client and the server? The specification is intentionally open so
that you can decide to a certain extent how to implement each feature.
• Is the design flexible? Would it be easy for you or someone else to add to or amend
the application to support additional functionality?
• Are all the required sections included in the report and completed appropriately?
Is the report lengthy and verbose or is it concise but full of significant
information? Is the standard of English adequate?

You will fail if any of the following are true:

• Your code does not run from the required web and database servers

• You do not attend the demonstration.

• You do not submit your documentation by the deadline

By D.F Page 9 01/02/2010

Assessment sheets

The assessment sheets require a circle to be drawn around one or more of the
following criteria for each row on the sheet.

none – missing or may as well be, no real attempt made

poor – fail, some evidence of work but falling way below the required standard
weak – a bare pass, lacking in essential aspects but not a fail
ok – acceptable, largely meets the specification but lacking in quality
good – first class, meets all of the specification to a high standard
excellent – faultless, difficult to criticise, outstanding work

The difference between these six categories should be perfectly clear. You should
seek timely guidance from your tutor if you require clarification. Try where possible
to refine your assessment by perhaps circling two adjacent criteria. For example,
having decided that a level is good you circle ‘good’. Now think again, is this level
really very good, in which case you should also circle ‘excellent’. Perhaps the level is
good but there are some significant flaws, poor coding, poor XHTML, weak
validation or some such, in which case you should also circle ‘ok’. If you find
yourself wanting to circle ‘excellent’ then please read the specification document very
carefully, submit your page to validator.w3.org and WebXACT and consider what is
meant by “faultless”.

Clearly there is a degree of academic judgement in making any assessment. The

assessment sheets are intended to help in making an objective assessment so please
consider each record carefully. It is in your interest to be honest and accurate in your
self assessment.

By D.F Page 10 01/02/2010

 COMP1309 Self Assessment Sheet for 2010 Coursework
This sheet must be completed and submitted with your report

Tutor Name: _________________________ Student name:_________________________________

URL: ___________________________________________________

Student Use
Level 1 : User registration none poor weak ok good excellent

Level 2 : User authentication none poor weak ok good excellent

Level 3 : Account verification none poor weak ok good excellent

Level 4 : Editing details none poor weak ok good excellent

Level 5 : Image uploading none poor weak ok good excellent

Level 6 : Personalisation none poor weak ok good excellent

Level 7 : Member search none poor weak ok good excellent

Level 8 : Report none poor weak ok good excellent

Properly commented code none poor weak ok good excellent

Form validation none poor weak ok good excellent

Adherence to good website design principles? none poor weak ok good excellent

Adherence to good software design principles? none poor weak ok good excellent

How good is the XHTML? none poor weak ok good excellent

How good is the CSS? none poor weak ok good excellent

How good is the JavaScript? none poor weak ok good excellent

How good is the PHP? none poor weak ok good excellent

Staff Use
The mark has been capped for following reasons:
• Code cannot be run at all i.e. not available from web server true false
• Submitted late true false
• Student did not attend demonstration true false
Any comments affecting the mark

Final mark
Do you have any reason to suspect plagiarism in this work?
e.g. similarities with other student’s code or the student’s inability to explain their code Yes / No
adequately? If so please investigate thoroughly and complete and submit a plagiarism report.

By D.F Page 11 01/02/2010