Web Technologies

  

Southampton Solent University

Coursework Assessment Brief

Assessment Details

 

Unit Title:	Web Technologies
Unit Code:	COM713
Unit Leader:	Prins Butt
Level:	7
Assessment Title:	Web Technologies
Assessment Number:	1
Assessment Type:	Report and Software Product
Restrictions on Time/Word Count:	2000 words
Consequence of not meeting time/word count limit:	There is no penalty for submitting below the word/count limit, but students should be aware that there is a risk they may not maximise their potential mark.
Individual/Group:	Individual
Assessment Weighting:	100%
Issue Date:	09th March 2020
Hand In Date:	15th June 2020
Planned Feedback Date:	13st July 2020
Mode of Submission:	Online via Solent Online Learning
Number of copies to be submitted:	1
Anonymous Marking	This assessment will be marked anonymously

 

Assessment Task

 

You are required to develop a database driven website using appropriate web technologies for a scenario of your choice.  Your website must meet the following criteria:

 

1) Database

 

The website must utilise a database. 

 

You are expected to design the database as you see fit for this assessment however it is expected that you will have a users table that holds all the users’ records.

 

You should also have at least two different types of users (for example, an admin user and a standard user).

 

You should include a database schema in your report

 

 

 

2) Back-End

 

You are not expected to use a back-end framework.  Instead you should demonstrate your own implementation using PHP.

 

 

3) Front-End

 

Your website should provide a means for the user to login as well as a dashboard/main page from which the key or main functionality of the website can be accessed.

 

It is expected that a basic solution will be based around standard technologies such as HTML, CSS and JavaScript.

 

 

4) Course Specific Skills

 

In addition to the above requirements you should demonstrate your understanding and implementation of web technologies that focus on the following:

 

Back End

Front End

API:   The back-end should be implemented as an API, that is, a set of modules with functions that allow at least the basic Create, Retrieve, Update and Delete (CRUD) operations to be executed.  This should be done using PHP.   A more advanced solution should some incorporate security features such as protection against common attacks (e.g. SQL injection and cross-site scripting attacks) and perform robust error checking.   Database:   The back-end should utilise a database.  A basic solution should consist of normalised tables which store and allow retrieval of login details as well as information relevant to the scenario.

Technologies:   The front-end should utilise a core web technologies (HTML, CSS and JavaScript). A basic solution should layout the user interface using suitable semantic elements and provide a basic look and feel.  A more advanced solution should provide a fully responsive front-end that supports progressive enhancement.   User Experience:   The front-end should incorporate  features that enhance the user experience.  A basic solution should provide a clear way to navigate the site.  A more advanced solution should demonstrate the application of techniques that enhance the user experience and perform data validation.

 

 

 

 

Deliverables

 

It is expected that you will produce two deliverables.

 

- An implementation.  This is your website deployed on provided server.

- A report.  This will summarise your implementation.

 

You need to complete both elements to pass this assessment.

 

 

The Implementation

 

Your implementation will be graded as follows:

 

 

For a Grade D

 

Develop a basic website that allows a user to create, search, view and delete entries stored in a database.  It is expected you will use standard web technologies such as HTML, CSS, PHP and MySQL.

 

For a Grade C

 

In addition to the requirements for Grade D, develop a website with:

 

a basic back-end API consisting of modules of functions that allow the creating, viewing, updating and deleting of database entries. 

 

a front-end that utilises the back-end API to populate the web pages and suitably structures and presents the content providing an intuitive way to navigate and/or utilise the key functionality of the website.

 

 

For a Grade A – B

 

In addition to the requirements for Grade C, the website provides:

 

A mobile-first, responsive website that complies with modern standards, utilises an appropriate framework and/or toolkit and supports progressive enhancement. 

 

The website will have a suitable back-end API and be database driven.  For the higher grades the implementation should incorporate security features and the application UX principles. For full marks the implementation should demonstrate the application of techniques beyond the taught aspects of this module.  

 

 

 

 

The Report

 

Your report should provide a summary of your implementation.  Your report will be graded as follows:

 

 For a Grade D

 

The report provides a summary of the key functionality that has been implemented and is consistent with the solution that has been submitted.  This should include details of the technical aspects or workings of the website (e.g. explains how a web page fetches data from the database and presents this to the user).  The report should also include an appropriate database schema.

 

 

For a Grade C

 

In addition to the requirements for Grade D, develop a website with:

 

The report summarises both the front-end and back-end aspects of the  implementation including the user experience, the front-end framework, back-end API and the database.  The report also includes a brief summary and evidence to demonstrate the use of a version control repository as well as the incremental development of the website (e.g. commit history).

 

 

For a Grade A – B

 

In addition to the requirements for Grade C, the website provides:

 

The report provides a concise and consistent summary of the implementation with strong supporting evidence of its development.  This should summarise all functionality that is equivalent to a Grade A – B implementation as indicated in the marking criteria for the implementation.

 

 

 

How and what to submit

 

You should use the assessment submission link provided on the Solent Online Learning (SOL) page for the module in order to submit your solution. 

 

You should submit a zip file containing your report and the website implementation including an SQL file with an export of your database. 

 

The website should also be deployed on the Edward 2 server and should not be modified once submission has been made.

 

 

Learning Outcomes

 

This assessment will enable students to demonstrate in full or in part the learning outcomes identified in the unit descriptors.

Late Submissions

 

Students are reminded that:

 

i.          If this assessment is submitted late i.e. within 5 working days of the submission deadline, the mark will be capped at 40% if a pass mark is achieved;

ii.        If this assessment is submitted later than 5 working days after the submission deadline, the work will be regarded as a non-submission and will be awarded a zero;

iii.       If this assessment is being submitted as a referred piece of work (second or third attempt) then it must be submitted by the deadline date; any Refer assessment submitted late will be regarded as a non-submission and will be awarded a zero.

 

http://portal.solent.ac.uk/documents/academic-services/academic-handbook/section-2/2o-assessment-policy-annex-1-assessment-regulations.pdf?t=1411116004479

 

Extenuating Circumstances

The University’s Extenuating Circumstances procedure is in place if there are genuine circumstances that may prevent a student submitting an assessment. If students are not 'fit to study’, they can either request an extension to the submission deadline of 5 working days or they can request to submit the assessment at the next opportunity (Defer).  In both instances students must submit an EC application with relevant evidence.   If accepted by the EC Panel there will be no academic penalty for late submission or non-submission dependent on what is requested.  Students are reminded that EC covers only short term issues (20 working days) and that if they experience longer term matters that impact on learning then they must contact a Student Achievement Officer for advice.

 

A summary of guidance notes for students is given below:

 

http://portal.solent.ac.uk/documents/academic-services/academic-handbook/section-4/4p-extenuating-circumstances-procedures-for-students.pdf?t=1472716668952

 

 

Academic Misconduct

Any submission must be students’ own work and, where facts or ideas have been used from other sources, these sources must be appropriately referenced. The University’s Academic Handbook includes the definitions of all practices that will be deemed to constitute academic misconduct.  Students should check this link before submitting their work.

 

Procedures relating to student academic misconduct are given below:

 

http://portal.solent.ac.uk/support/official-documents/information-for-students/complaints-conduct/student-academic-misconduct.aspx

 

 

 

Ethics Policy

The work being carried out by students must be in compliance with the Ethics Policy. Where there is an ethical issue, as specified within the Ethics Policy, then students will need an ethics release or an ethical approval prior to the start of the project.

 

The Ethics Policy is contained within Section 2S of the Academic Handbook:

http://portal.solent.ac.uk/documents/academic-services/academic-handbook/section-2/2s-university-ethics-policy.pdf

 

 

Grade marking

The University uses a letter grade scale for the marking of assessments. Unless students have been specifically informed otherwise their marked assignment will be awarded a letter grade. More detailed information on grade marking and the grade scale can be found on the portal and in the Student Handbook.

 

Policy:          http://portal.solent.ac.uk/documents/academic-services/academic-handbook/section-2/2o-assessment-policy.pdf

 

 

Guidance for online submission through Solent Online Learning (SOL)

 

http://learn.solent.ac.uk/onlinesubmission

 

 

 

Read More

Software Design and Development

 

Southampton Solent University

Assessment Brief

Assessment Details

 

Unit Title:	Software Design and Development
Unit Code:	COM714
Unit Leader:	Prins Butt
Level:	7
Assessment Title:	Tourist Office
Assessment Number:	1
Assessment Type:	Software Artefact with Report
Restrictions on Time/Length :	2000 Words for Report + Software Artefact
Individual/Group:	Individual
Assessment Weighting:	100
Issue Date:	16th March 2020
Hand In Date:	8th June 2020
Planned Feedback Date:	6th July 2020
Mode of Submission:	Online
Mode of Marking:	Online
Mode of Feedback:	Online
Number of copies to be submitted:	1

 

 

 

 

Scenario

 

An internationally well-known city is developing an application, to be installed in tourist offices, to allow tourist information centre staff to look up and book hotels in the city on behalf of customers.

 

A tourist would visit the tourist office and ask the staff to look up hotels of a given star rating, where 1-star is the cheapest and 5-star the most expensive. The tourist office staff would then search for matching hotels using the application.

 

Having searched for a hotel, the tourist office staff should then be able to view the full details of a given hotel and book it for the tourist.

 

The application should also allow staff to add new hotels.

 

 

Task

 

Your task is to analyse this problem and design, build and test a prototype application in Java using a Swing GUI. (You do NOT need to worry about the implementation details of touchscreen applications.)

 

To do this, you should do the following:

 

a) Derive an initial domain model for this scenario.

b) Draw up a use case diagram for the following use cases:

 

* View full details of a given hotel by name (assume that no two hotels have the same name). Full details should include price, address and number of free rooms.

* Search for hotel by star rating

* Book a hotel. Payment does not need to be taken, this is done when the tourist visits the actual hotel.

* Add a new hotel

 

c) Create initial, analysis-level use-case texts for the use cases above.

d) Using the use-case texts and domain model, draw up robustness diagrams for the use cases above.

e) Use the robustness diagrams to refine the use-case texts and domain model, as appropriate.

f) Draw up sequence diagrams for the use cases above.

g) Use the sequence diagrams and domain model to derive a class diagram for the system.

h) Implement the system in Java using a Swing GUI.

 

Report

 

Your analysis, design and testing artefacts and code must be accompanied by a report. This should include discussion of the following (half a page to a page for each - I am not looking for reams and reams of text!):

 

* Decisions you made when drawing up your domain model and use-case texts.

* Any new objects discovered when drawing up your robustness diagrams.

* Detail on any changes made to the domain model or use-case text as a result of drawing up your robustness diagrams, and why.

* Any decisions made when drawing up your sequence diagrams

* Detail on places where your code did not match your design, and why.

* Critical evaluation of your code and/or design

 

Handing in

Please upload a ZIP file to SOL containing all your code, analysis and design artefacts and report by the deadline.

Marking Criteria

 

	A1-A4	B1-B3	C1-C3	D1-D3	F1-F3
Analysis and design (30%)	Work fully complete; additional considerations beyond the basics have been made in your design. Analysis and design artefacts all consistent with each other.	Work complete, analysis and design correct and artefacts all consistent with each other (a small number of inaccuracies or inconsistencies are permissible for a lower B).	Work complete, diagrams predominantly correct and consistent with each other, but with a number of inaccuracies.	Work mostly complete; significant inaccuracies and/or inconsistencies in your analysis and design.	(F1) Some parts of the analysis and design completed, but others incomplete. (Lower F) minimal effort.
Implementation (50%)	An implementation of all specified use cases which makes use of the more advanced implementation technologies covered in the unit. Robust error handling and a user-friendly interface. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	All specified use cases implemented. There may be room for improvement in your error handling. Some evidence of use of the more advanced implementation technologies covered in the unit. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	At least three out of four use cases implemented. Little error handling. Little evidence of use of the more advanced implementation technologies covered in the unit. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	At least two use cases implemented, one of which should be something OTHER than the "search for hotel" or “view full details of hotel” use case. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	A minimal effort; up to one use case (or the "search for hotel" and “view details of a hotel” use cases) successfully implemented.
Report (20%)	Clear justifications of decisions made when drawing up your analysis and design artefacts. including insightful comments. Considerations beyond the basics are made.	Clear justifications of decisions made when drawing up your analysis and design artefacts.	Largely clear justifications of decisions made when drawing up your analysis and design artefacts but unclear at times.	Writeup clear and accurate in some places but unclear and/or inaccurate in others. A significant number of omissions.	Predominantly unclear and/or inaccurate writeup. Little understanding demonstrated

 

Implementation must match the design!

 

Please note that it is not possible to achieve higher than a grade D at best for an implementation which significantly differs from your design, unless you clearly and satisfactorily describe the reasons for the difference in your writeup. Grades for the implementation criterion will be reduced as follows if your code is significantly different from the design, and you do not provide a satisfactory reason why (a partial mismatch will result in a partial reduction):

 

Original grade	Reduced grade
A1 to A4	D1 to D3
B1 to B3	F1
C1 to D3	F2
F1 to F3	F3

 

Other information

Copyright

Please note that using images or text from other websites is infringing copyright and is therefore illegal and not to be done! The only exceptions are if the source website has given you permission, or the material is available in the public domain or under a liberal licence (e.g. Creative Commons). By all means use creativity in the design of your app (though note that you will not be given credit for visual design), but use your own material or material you are legally allowed to make use of.

Learning Outcomes

 

This assessment will enable students to demonstrate in full or in part the learning outcomes identified in the unit descriptors.

Extenuating Circumstances

The University’s Extenuating Circumstances procedures are in place if there are genuine circumstances that may have affected your academic performance. Remember however you need to be ‘fit to study’, this means that you can either submit your assessed work or declare extenuating circumstances, but you cannot do both.

A summary of guidance notes for students is given below:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234570925

 

Academic Misconduct

Any submissions must be your own work and, where facts or ideas have been used from other sources, these sources must be appropriately referenced. The University’s Academic Handbook, includes the definitions of all practices that will be deemed to constitute academic misconduct. You should check this link before submitting your work.

Procedures relating to student academic misconduct are given below:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234570157

 

Ethics Policy

The work being carried out by the student must be in compliance with the Ethics Policy. Where there is an ethical issue, as specified within the Ethics Policy, then the student will need an ethics release or an ethical approval prior to the start of the project.

The Ethics Policy is contained within Section 2S of the Academic Handbook:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234569791

 

 

Anonymous Marking

A copy of the University’s Policy on Anonymous Marking, process details and student guidance on submission sheet completion can be found on the following links, which are also uploaded on the Student Portal.  The guidance ‘fact sheet’ will be available at Faculty Reception Points.

Policy:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234574213

Process:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234574215

Fact Sheet:  http://docman.solent.ac.uk/DocMan8/OCSFile?RN=1234574214

 

Grade marking

The University uses a letter grade scale for the marking of assessments. Unless you have been specifically informed otherwise your marked assignment will be awarded a letter grade. More detailed information on grade marking and the grade scale can be found on myCourse. The guidance ‘fact sheet’ is available at the Faculty Reception Points.

Policy: http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234569864

Fact sheet:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234576014

 

 

 

 

 

 

 

 

Read More