联系方式

  • QQ:99515681
  • 邮箱:99515681@qq.com
  • 工作时间:8:00-23:00
  • 微信:codinghelp

您当前位置:首页 >> Web作业Web作业

日期:2020-11-20 10:58

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website.

Faculty of Engineering, Environment and Computing

304CEM Web API Development

Assignment Brief

Module Title

Web API Development

Individual

Assignment

Cohort

Sept

Module Code

304CEM

Coursework Title (e.g. CWK1)

Coursework 1: RESTful API with client, video demo and short report

Hand out date:

29/09/20

Lecturer

Colin Stephen

Due date and time:

Date: 07/12/20

Online: 18:00:00

Estimated Time (hrs): 50-75

Word Limit for Report: 3000 / 8 pages

Length Limit for Video: 5 minutes

Coursework type:

Individual Practical plus Written

Report and Video

% of Module Mark

100%

Submission arrangement online via Aula: Upload through assignment link

File types and method of recording: 1x PDF document containing a written report and URL links (to two

git repositories and to your uploaded application demonstration video).

Mark and Feedback date (DD/MM/YY): 21/12/20

Mark and Feedback method: rubric marks and written comments

Module Learning Outcomes Assessed:

1. Develop a secure, open-standards-based API to support server-client communication.

2. Create modern web content involving asynchronous data retrieval, client-side DOM

manipulation, standards adherence and user-user interaction.

3. Manage data persistence cross both server and client web-based solutions.

4. Design and implement an API and client based on given, non-trivial requirements using a range

of appropriate developer tools.

Task and Mark distribution:

1. Back-end RESTful API: 40%

2. Front-end Single Page Application: 35%

3. Report on technology resources for full stack JS web development: 20%

4. Video demonstration of application functionality: 5%

Notes:

1. You are expected to use the Coventry University APA style for referencing. For support and

advice on this students can contact Centre for Academic Writing (CAW).

2. Please notify your registry course support team and module leader for disability support.

3. Any student requiring an extension or deferral should follow the university process as outlined

here.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

4. The University cannot take responsibility for any coursework lost or corrupted on disks, laptops

or personal computer. Students should therefore regularly back-up any work and are advised to

save it on the University system.

5. If there are technical or performance issues that prevent students submitting coursework

through the online coursework submission system on the day of a coursework deadline, an

appropriate extension to the coursework submission deadline will be agreed. This extension will

normally be 24 hours or the next working day if the deadline falls on a Friday or over the

weekend period. This will be communicated via your Module Leader.

6. You are encouraged to check the originality of your work by using the draft Turnitin links on Aula.

7. Collusion between students (where sections of your work are similar to the work submitted by

other students in this or previous module cohorts) is taken extremely seriously and will be

reported to the academic conduct panel. This applies to both courseworks and exam answers.

8. A marked difference between your writing style, knowledge and skill level demonstrated in class

discussion, any test conditions and that demonstrated in a coursework assignment may result in

you having to undertake a Viva Voce in order to prove the coursework assignment is entirely your

own work.

9. If you make use of the services of a proof reader in your work, you must keep your original version

and make it available as a demonstration of your written efforts.

10. You must not submit work for assessment that you have already submitted (partially or in full),

either for your current course or for another qualification of this university, with the exception of

resits, where for the coursework, you may be asked to rework and improve a previous attempt.

This requirement will be specifically detailed in your assignment brief or specific course or module

information. Where earlier work by you is citable, i.e. it has already been published/submitted,

you must reference it clearly. Identical pieces of work submitted concurrently may also be

considered to be self-plagiarism.

Mark allocation guidelines to students – this applies to the code the report and the video. Please

see detailed rubrics at the end of the document.

0-39 40-49 50-59 60-69 70+ 80+

Work mainly

incomplete

and /or

weaknesses in

most areas

Most elements

completed;

weaknesses

outweigh

strengths

Most elements

are strong,

minor

weaknesses

Strengths in all

elements

Most work

exceeds the

standard

expected

All work

substantially

exceeds the

standard

expected

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

Assignment Brief

Scenario

As a full stack web developer, you have been asked to develop a Node based RESTful

API on the backend plus a React JS single page application (SPA) on the frontend to

replace a client’s existing unmaintained PHP-based website. In addition to the API

and SPA, the client requires a short report targeted at their internal development team,

exploring how the developed application fits in to the wider context of JavaScript full

stack technologies. Finally, the client has requested a short video demonstration of the

application, targeted at end-users.

Please choose ONE client from the list of two at the end of the brief for your

assignment.

The application specifications and requirements are set for you in the client’s project

brief. Please note that it is very important to follow the requirements and the design

considerations listed for each application. What follows next are instructions relevant

to all of the client projects.

Code – General Requirements

The application itself should be composed of reusable components rather than a single

stand-alone application. That means your code architecture should allow you to plug

in or extract any component easily from your application. For example, if you are

required to create a feature that allows users to comment on an item and reply to other

users’ comments, then you would develop a component to handle this commenting

functionality on its own, independent from and reusable in other full stack

applications when required.

Backend

All the backend services you develop should provide a Node JS based RESTful API.

This must communicate with your application using the JSON data format by default.

The Node frameworks and modules you choose to build the backend are up to you:

options include Koa, Express, Restify, and others.

Database

Similarly, the choice of database integration on the backend is up to you: options

include MySQL, SQLite, MongoDB, and others.

Frontend

All the frontend components you develop should be React JS components. In terms of

visual design the CSS framework you choose, if you decide to use one, is up to you:

options include React Bootstrap, Ant Design, Material UI, and others.

If in doubt as to the suitability of a particular framework, Node module, or DBMS

please ask the Module Leader first.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

Code – Professional Practice

Your workflow, software architecture, coding style and conventions, and

documentation should follow general good practice as introduced in this module.

Above all:

? Your code should be consistent, readable and well documented. However,

your choice of specific code convention(s), such as using JavaScript Promise

chains versus async … await expressions, or what style you use to lint your

code, is up to you.

? Your API functionality should be clearly documented for other developers,

either in text-based documentation files (such as Markdown) in your

repository, or as HTML documentation created with a framework such as API

Blueprint or Swagger.

? Your SPA functionality should be clearly documented for end-users, either

in text-based documentation files (such as Markdown) with appropriate

screenshots, in your repository, or as HTML-based user documentation.

Code – Key Constraints

You should use only the programming languages and frameworks as advised in this

brief, no other alternatives are permitted:

? JavaScript with a preference for ES6 language constructs

? React JS on frontend

Written Report

Your client has asked for a background report to be compiled for their development

team, who are unfamiliar with the JavaScript full stack ecosystem.

The report should cover 6-8 one-page topics (see below for sources) chosen to

illustrate:

? the benefits of full stack for application development,

? how the JS full stack ecosystem is developing at its cutting edge,

? emerging commercial best practices the developers should be aware of.

To choose the topics and write the report:

? browse the archives of the following industry newsletters, or subscribe:

o JavaScript Weekly

o Node Weekly

o React Status

? choose 6-8 resources linked from them, keeping the report objectives in mind

? summarise each resource and explain its significance: why should the

development team be made aware of it (maximum 1 page per resource).

The final report should be clearly formatted for readability and include screenshots,

external references, and examples from your own application code when appropriate.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

The maximum length of the report should be 8 A4 pages including references.

Video Demonstration

Your client wants to quickly introduce the new full stack application to its product

team and end users. For this purpose, they have requested that you provide a video

demonstration of the application functionality.

Produce a video walk-through of your application’s features and functionality using

screen recording software such as Microsoft Stream’s browser-based screen recording

or a one-person Zoom meeting recording with shared screen.

There should be no audio on the recording. Instead you must communicate using text

on the screen: e.g. prepare a slide deck with descriptions of the demonstration steps

being carried out.

The length of the video should be between 2-5 minutes and it must be uploaded to

Coventry University’s Microsoft Stream page (log in with your Coventry University

credentials).

The uploaded video can be private, but you must provide full access to Colin Stephen

(CU username ab5169) and be prepared to give access to other CU staff if requested.

A demonstration of how to do this will be given in class before the Coursework

deadline.

Task Summary

To prepare your final submission a rough breakdown of the key tasks is as follows.

First Steps

? Review the client projects at the end of this document and choose one.

? Decide on a database to use and a Node framework to build the API with.

? Sign up for the three industry newsletters linked above.

? Set up two repositories on https://github.coventry.ac.uk/304CEM-

2021SEPJAN, one for your frontend code and its documentation and one for

your backend code and its documentation.

? Prototype and plan your project based on the client requirements.

o Wireframe or sketch the UI, decide which UI components to develop

and decide how these will fit together in a React component hierarchy.

o Design a data schema for a database to store the API data you need to

manage. An Entity-Relationship diagram can be useful for this.

o Be clear on what the main resources provided by the API are.

o Design an appropriate JSON representation of these API resources.

Often this will parallel your DB schema, but it may differ if your

database contains additional information or relationships.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

o Design the URI endpoints of your API and which HTTP methods can

be used to access them, corresponding to the resources you wish to

expose, using RESTful principles.

During Semester

? Develop your back- and front-end code with associated project and in-line

documentation using good version control practices and testing:

o Make regular small git commits with relevant messages.

o Develop features on new branches.

o Fix bugs on new branches.

o Merge branches with features and fixes to the master branch only once

complete.

o Write tests for key parts of your code using an appropriate test

framework such as Jest, Mocha, or Jasmine.

? Write your full stack development resource summaries in your report

o e.g. one page per week describing one relevant resource

? Extend your API documentation and end-user documentation as your code and

features develop.

Before Submission

? Commit your final code changes and merge all code to be assessed into your master

branch. Push all branches of your repositories to the remote origin branches in your

repositories on https://github.coventry.ac.uk/304CEM-2021SEPJAN before the

submission deadline. Code committed after the deadline will be ignored.

? Record a video demonstrating your final application, upload it to Microsoft

Stream and ensure the Module Leader (username:ab5169) has full access

before the submission deadline. Videos published after the deadline will be

ignored.

? Complete your report with an introduction and conclusion.

? Add a final blank page to your report and to it add three URL links to:

o your frontend repository on CU GitHub

o your backend repository on CU GitHub

o your uploaded video on CU MS Stream

? Export/Print your report-plus-URLs document to PDF format.

Submission

Upload a single PDF file, containing the following, to the assignment link on Aula:

? your report,

? the URLs for your repositories and video.

Files submitted after the deadline will not be marked unless you have been

awarded an extension or deferral from Registry.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

Client Projects

Client 1 – We Sell Houses: A Real Estate Listings Web App

We Sell Houses would like a new web application that allows users (estate agents) to

list houses for sale to the general public.

Main features

? The general public can

o view a list of all items (properties)

o search/filter items based on their features and/or keywords

o view any item detail

o message item owners (estate agents) to express interest

? New users (estate agents) can register on the app if they have a sign-up code

o They need to supply a unique email and a password to sign up

o For this prototype the sign-up code is always “we_sell_houses_agent”

? Registered users can

o log in to the app

o see their current list of properties

o search/filter their current list of properties

o add a new item (property) for sale

o add or update the item category (commercial, terrace, apartment, …)

o add or update a description

o add or update a list of features

§ “has garden”,

§ “needs refurbishment”

§ etc.

o add or update an asking price,

o add or update the location

o attach or delete images

o mark as “under offer”

o archive/unpublish the item (property) from sale so it is no longer visible

to the public

o delete an item entirely

o mark an item as ‘high priority’

o view the current list of high priority items

o view all messages sent from the general public

o view, archive, or delete an individual message sent from the general

public

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

Challenge features – choose one or more:

? Agents can upload video walk-throughs for their listings

? Send in-browser notifications to the user when they receive a new message

? Use the Zoopla API, or similar, to provide agents with average historical

house sale prices in the location of their individual items, or other relevant

data. External data should be stored in your API database when retrieved, not

queried from the external API each time.

? Confirm the user’s email when they sign up by sending them an email

message containing a validation link that needs to be clicked to validate.

Client 2 – Public Library: A Book Lending Web App

Due to recent physical branch closures, a consortium of local libraries across the

country have teamed up. They wish to provide a platform for their members to lend

their books to one another online.

Main Features

? The general public can

o list all items (books) available on the site

o search/filter items based on their features and/or keywords (author, title,

ISBN, etc.)

o view any item detail

? New users can register on the app

o They need to supply a unique email and a password to sign up

o They must also provide a mailing address for book postage

? Registered users can

o log in to the app

o add new items (books) available for borrowing

o view individual book details

o update any fields describing their book

o delete a book they own

o attach or delete book images

o see a list of owned books

o search/filter owned books (author, title, ISBN, etc.)

o request or cancel a request to borrow another user’s item

§ only books not marked ‘on loan’ can be requested

§ only books not marked ‘requested’ can be requested

§ a short message to the lender can be added to the request

o view requests made and requests received

§ each request should also include any messages associated to it

o archive a request and its associated chat messages

o reply to messages in requests

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.

o view user details of the user who is requesting a book

o mark any book as ‘on loan’

§ if the book had an open request then this request is removed

o mark any book as ‘available’ (meaning no longer ‘on loan’)

Challenge features – choose one or more:

? Send in-browser notifications to the user when they receive a new book

request

? Use the Goodreads API, or similar, to provide additional item information for

each book: reviews, author information, etc. External data should be stored in

your API database when retrieved, not queried from the external API each

time.

? Confirm the user’s email when they sign up by sending them a message

containing a validation link.

? Allow the user to download a CSV file of all currently available books in the

app.

This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third

parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.

304CEMMarksBreakdownandRubricforBackendAPI(40%)

0 1 2 3 4 5

Version Control

5%

No access given

to the remote

repository.

Code does not match

the code demonstrated

or the project

requirements.

No evidence of regular

commits.

Evidence of regular commits. Evidence of regular

commits over an extended

period of time. Minor use of

branching.

Evidence of regular commits

over an extended period of time.

Effective use of branching and

merging.

API

Architecture

5%

No API code

supplied.

An attempt to write the

API however it fails to

work correctly.

All code for routing and

business logic

maintained in a small

number of files.

Code split into several smaller

files but shows overlap between

routing, business, and

persistence logic in places.

Clear separation between

core API routing, business,

and persistence logic.

Evidence of clear separation

plus encapsulation of

functionality into fully pluggable

and well documented modules.

API Design and

Testing

10%

No API code

supplied.

An attempt has been

made to implement a

basic API however this

does not work as

expected.

Simple functional API

demonstrating a basic

understanding of REST

principles (resources,

collections, methods and

headers).

The API is fully functional. The

API demonstrates a good

understanding of REST principles

with effective URI design and

JSON data representations.

Some attempt at testing

endpoints has been made but

this may be flawed or minimal.

The API provides feedback

for invalid requests through

appropriate response codes

and messages. Includes

filtering and sorting and

conditional GET requests.

Several API actions have

been tested.

Fully REST-compliant API

including implementation of

HATEOAS principles. Uses the

full range of request and

response headers and caching

where relevant. Many or most of

the API endpoints have been

tested with a standard test

framework.

Code Quality

and Unit Testing

10%

No API code

supplied. No test

code supplied.

An attempt has been

made to write code to

implement some of the

basic functionality

although this may not be

successful. No or limited

attempt at flawed tests.

Working code base

showing the application

of basic programming

principles. Code may

contain linting errors and

warnings. An attempt

has been made to write

some tests.

Well written code with

inconsistencies in some places.

Some code duplication. Would

benefit from mild refactoring.

Error handling is present but may

have holes. Validation is present

but may not cover all possible

issues. Evidence of a limited

number of tests written and run.

The code is modular,

follows a consistent style,

and includes full or close to

full exception-handling.

Data are thoroughly

validated before passing to

the persistence layer. Most

complex functions have

tests defined.

The API demonstrates a wide

range of appropriate language

constructs including clear

modular structure and use of

abstract design patterns or

paradigms such as functional

programming. Concise easily

maintainable code. Wide range

of relevant automated tests

defined.

User

Authentication

No user

authentication.

An attempt at user

authentication has been

Simple authentication

that allows users to login

An authentication system that

allows users to login using JSON

Fully working authentication

system using JWT or more

Fully working authentication

system that allows multiple

This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third

parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.

and

Authorization

5%

made but it is not

functional or is insecure.

using Basic Auth. There

is no difference in user

permissions or user

roles.

web tokens. Limited use of user

permissions or user roles.

advanced techniques.

Includes effective user

permissions and/or roles to

provide appropriate

protection to data.

different authentication

methods. Provides a flexible

roles and permissions structure

that allows an admin to manage

permissions without changing

code.

API and Code

Documentation

5%

No

documentation

provided.

Basic limited

documentation in code

and/or text documents

that does not add much

more understanding

than reading the code

itself.

Attempt at documenting

code or API but one or

the other is not fully

presented.

Both API and code are

documented well but could be

more detailed on key aspects

such as URIs or JSON data

structures. Code documentation

would benefit from a more

standardised approach such as

JSDoc or similar.

Clearly presented and

standardised

documentation on API URI

endpoints and JSON data

structures used by the API.

Code documentation uses

JSDoc or similar. Could be

easier to read or better

formatted

Extensive well formatted

interactive HTML-based API

documentation at a professional

level. Extensive relevant code

documentation adding clarity

and maintainability.

304CEMGradingRubricforFront-end Application (35%)

0 1 2 3 4 5

Documentation

5%

No attempt Limited code

documentation and no

user documentation.

Or vice versa.

An attempt to comment

occasionally on the code, an

attempt to generate user

documentation but lacking

any detail.

Some of the code is

commented, an attempt to

generate user

documentation but still needs

more work to be complete.

Most of the code is commented

to a level that would help with

maintenance. A clear but short

user manual has been created.

Fully commented code using

JSDoc or similar, all user

functionality and every app

feature have been clearly

explained and professionally

presented.

Connecting to

APIs

5%

No code

supplied, or

no attempt to

connect to

the API.

An attempt for

connecting and

retrieving data from the

APIs was done but this

does not work or is

incomplete.

Some pages connect and

retrieve data from the API.

These may have minor or

major issues in connecting.

Some connections are not

attempted.

Most of the pages connect

and retrieve data from the

API with few having minor or

major issues in connecting

All pages/components connect

and retrieve data from the API.

Some potential issues remain

due to error handling.

All pages connect and retrieve

data from the API, with

appropriate error handling in

place for unusual situations

such as timeouts etc.

This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third

parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.

Front-end code

Architecture

5%

No code

provided or no

attempt at

architecture.

An attempt for a frontend

code architecture was

made, but it is not

working properly, or it is

mostly incomplete

Code architecture is not

complete, with major flaws in

some pages. Attempts to use

React components for major

application parts only.

Generally good architecture that

needs improving in some

places. React components have

a clear hierarchy but could be

broken down further.

Good architecture with some flow in

the design of the code. Good choice

of component hierarchy, use of

raising state or other appropriate

methods for sharing app data.

Clear architecture and component

hierarchy enabling effective

communication between all

interacting components.

Design and UX

10%

No CSS used

at all. Unusable

interface.

Attempt to lay out unstyled

or minimally

styled components but

app is convoluted and

may not display

correctly.

A CSS framework has been

chosen to enable consistent

formatting and layout. However,

this has only been minimally

implemented and better

component choices could have

been made. May have glitches

in the interface such as having

to refresh to update.

A responsive layout with

appropriate use of a CSS

framework to style components

in appropriate ways. Generally

good UX. May have minor

issues in navigating or receiving

instant feedback. Some controls

are unintuitive.

Sophisticated layout and design

reflecting a well-thought-out

application. Good UX, good

navigation, may still have minor

issues in interacting with controls

but generally smooth.

Effective design with advanced

elements such as theming. Design

is fully accessible and would

work well on desktop or mobile.

Very well designed UX smooth

navigation, instant feedback,

quality interface

Front-end Code

and testing 10%

No code

supplied. No

test code

supplied.

An attempt has been

made to write code to

implement some of the

basic functionality

although this may not

be successful. No

testing.

Working code base showing

the application of basic

programming principles.

Code may contain linting

errors and warnings. No or

limited testing.

Well written code with

inconsistencies in some

places. Some code

duplication. Would benefit

from mild refactoring. Error

handling is present but may

have holes. Validation is

present but may not cover all

possible issues.

The code is modular, follows a

consistent style, and includes full

or close to full exceptionhandling.

Data are thoroughly

validated before passing to the

API layer or to LocalStorage.

Some tests are defined but could

be more extensive.

The SPA demonstrates a wide

range of appropriate language

constructs including clear

modular structure and use of

abstract design patterns or

paradigms such as functional

programming. Concise easily

maintainable code. Wide range

of automated tests defined.

304CEMGradingRubricforFullStackTechnologyReport(20%)

0 1 2 3 4 5

6-8 Resource

Summaries and

their Relevance

to the Client’s

Development

Team 15%

No

attempt

Attempt to

summarise resources

but selections are

irrelevant, too

complex, or were

misunderstood.

Short summaries with some

indication of relevance to

the Client’s development

team. No concrete examples

of how the key points from

the resources will impact the

Concise summaries of interesting

and/or relevant resources showing

some understanding of the wider full

stack development ecosystem and

how the developed application fits in

to it, with some reasonable

Relevant resources identified.

Clear summary of each resource

including accurate evaluation of

key points. Good reflection on how

these points are likely to affect the

client team as they build new

Chosen examples clearly illustrate the

benefits of full stack for application

development, how the JS full stack

ecosystem is developing at its cutting

edge, and emerging commercial best

practices the developers should be aware

This document is for Coventry University students for their own use in completing their assessed work for this module and should not be passed to third

parties or posted on any website. Any infringements of this rule should be reported to facultyregistry.eec@coventry.ac.uk.

further development of the

full stack application. Some

sources may be irrelevant.

suggestions for the client

development team to keep in mind

moving forward.

features into the new full stack

API+SPA application, with some

concrete references to the app

itself.

of. Gives direct relevant examples from

the API+SPA application that was

developed. Provides concrete suggestions

regarding technology, tooling, and

workflow choices for the client

development team moving forward.

Report

Presentation 5%

No

attempt

Report submitted

is incomplete or

not formatted in a

readable way.

Report contains

formatting issues, does

not clearly separate the

resources discussed, and

may also have errors in

written language.

Readable report with introduction,

separate sections for each

resource, and conclusion. Limited

use of screenshots/code where

these would have been useful.

References are not correctly

formatted.

Good accessible report

presentation with appropriate

links/references and visualisations

where appropriate. Good use of

language to express complex

topics.

Professional level presentation with

no issues in language use or

formatting.

304CEMGradingRubricforVideo(5%)

0 1 2 3 4 5

Enduser


Demo

Video

5%

No video

submitted

A video

was

submitted

Video shows the

application working but

it does not make all the

user functionality clear.

Core functionality is presented, and text

descriptions are used to signpost the viewer at key

stages of the presentation. Major or minor glitches

in the app functionality may appear but if so, they

are limited to non-core functionality or UX, not

data.

High quality video exploring core and additional

functionality. Text guidance is user-centric and

well thought out. Minor or no glitches in the

application while it is being used.

Professional level demonstration suitable for

end-users to get a clear idea of how the

application works and what it is capable of.

Application is demonstrated smoothly, with

an appropriate text narrative taking the user

on a journey through the application.

This document is for Coventry University students for their own use in completing their

assessed work for this module and should not be passed to third parties or posted on any

website. Any infringements of this rule should be reported to

facultyregistry.eec@coventry.ac.uk.


相关文章

【上一篇】:到头了
【下一篇】:没有了

版权所有:留学生编程辅导网 2018 All Rights Reserved 联系方式:QQ:99515681 电子信箱:99515681@qq.com
免责声明:本站部分内容从网络整理而来,只供参考!如有版权问题可联系本站删除。