INTI International College Penang School of Engineering and Technology

3+0 Bachelor of Science (Hons) in Computer Science, in collaboration with Coventry University, UK
3+0 Bachelor of Science (Hons) in Computing, in collaboration with Coventry University, UK

Coursework cover sheet

Section A - To be completed by the student

Full Name:

CU Student ID Number:

Semester: April 2021

Lecturer: Vimala Doraisamy

Module Code and Title: 302CEM Agile Development

Assignment No. / Title: 50% of Module Mark

Hand out date: 12th April 2021 Due date: 18th July 2021

Penalties: No late work will be accepted. If you are unable to submit coursework on time due
to extenuating circumstances you may be eligible for an extension. Please consult the
lecturer.
Declaration: I/we the undersigned confirm that I/we have read and agree to abide by the University
regulations on plagiarism and cheating and Faculty coursework policies and procedures. I/we confirm
that this piece of work is my/our own. I/we consent to appropriate storage of our work for plagiarism
checking.

Signature(s): --------------------------------------
Section B - To be completed by the module leader
Intended learning outcomes assessed by this work:
1. Demonstrate a sound understanding of how Agile Methodologies can be used to
define users’ requirements, analysis and design of information systems.
2. Compare and contrast a range of current and emerging agile methodologies.
3. Evaluate the methods, techniques and tools for rapid development of various types of
information systems, and the reasons for their selection and use.
4. Use a range of appropriate tools to contribute to the development of a solution to a
real-world problem.
Marking scheme Max Mark
1. Agile Processes 15
2. Team Dynamics 5
3. Version Control 10
4. Test Driven Development 10
5. The Product 10
Total 50
Lecturer’s Feedback

Internal Moderator’s Feedback

Task Description
Assignment Brief
The purpose of this assignment is for you to practice the Agile development process
and to reflect on the experience you gain. You will be working in teams of between 3
and 5 people to develop a system of your choice.

The coursework is divided into two elements:

1. a final product containing a full-stack solution which will be assessed as a group
(10%)
2. and a reflective report which is an individual contribution (40%)
System Brief
You have several options to develop your full-stack solution as given below. You are
not allowed to rebuild or extend software projects from other subjects or other
students’ work.

(A) Startup

If you have completed the Hi-Tech Entrepreneurship subject, you already have a
good startup idea. You now have the chance to start developing your idea. It is
your own responsibility to form your team and inform your module leader at the
earliest opportunity about your system title and your team members.

(B) Book Shop

Build a website for an online company selling books.

Testing

The system should include the data for at least 10 real books and include the
correct details for each. The customer details should also be valid.

You are required to create the following accounts to allow the system to be
tested. All accounts should have the password p455w0rd:
1. customer1
2. customer2
3. admin.

Stage 1

The core functionality consists of three screens.

Part 1

If the user is logged in with the admin account they should see a Stock

levels button on the home page. This should take them to a Stock Levels screen
which should have an Add stock button. Clicking this should take them to
an Add Stock screen which contains a form where they can add new books to the
system. This should request the following information:
1. The name of the book.
2. The author of the book.
3. A data picker allowing the publication date to be set.
4. The ISBN-13 number.
5. The multiline book description.
6. A picture of the front cover.
7. A slider allowing the trade price to be set (max $500).
8. A slider allowing the retail price to be set (max $500).
9. A slider allowing the quantity of books to be set (max 20).

The ISBN-13 number should be considered the primary key. If stock is added for
a book that is already in the system it should update the existing record rather
than adding a new one.

Part 2

The Stock Levels screen should display the books that have been added to stock
using the form from the part 1 task. This page should display:

1. A thumbnail picture of the front cover.

2. The book title.
3. The ISBN-13 number.
4. The quantity in stock.

Part 3

Each book on the Stock levels screen should have a Details link or button. This

should take the admin user to a Book Details screen that displays all the
information about the book including cover image, description, prices and the
number in stock.

A home page that should be visible without logging in. This should display all the
books that are for sale. For each book the following should be shown:

1. The name of the book

2. The name of the author
3. A thumbnail image
4. A price

Stage 2

1. The following information about all the books in stock should be visible on the
homepage without needed to log in:
i. The name of the book
ii. The name of the author
iii. A thumbnail image
iv. A price
2. If a user is logged in there should be an Add to cart button next to each book.
Clicking this adds the book to a shopping cart and displays the cart page. The
 cart should have a Continue shopping link or button to take the user back to
the homepage.
3. The cart should handle adding the same book twice by changing the quantity
and should display the total costs of all the items in the cart.

Stage 3

1. If the quantity of any book drops to zero it should not be possible to add the
item to the cart and it should be flagged as out of stock until the admin
increases the stock level.
2. The shopping cart should enable the user to adjust quantities of each item
and remove items with the correct total always being displayed.
3. There should be a checkout link or button on the shopping cart page. This
takes the user through the checkout process, prompting for an address if
none can be found and storing this in the user profile for future orders.
4. There should be an Order history button for the admin user which lists all the
orders placed on the system together with their details and value.

Extras

In some assignment briefs you are given marks for the appropriate use of media
and using sensors built into the user's device.

Sensors

In some assignment briefs you are given marks for the appropriate use of
sensors and sensor data. You should be implementing:

1. When a custotomer places an order the system should automatically

determine which country they are ordering from and use this to calculate the
delivery cost.
2. When the customer checks out the order, the address field(s) should be
prefilled based on their current location but they should be able to correct
this.
3. The user should be able to use their device camera (if available) to scan a
barcode which either adds the book to the cart or flags it up as invalid.

Media

In the requirements listed above you need to provide the user with the ability to
upload photos. For the extra media marks you will need to expand this by:

1. Providing the user with the choice of uploading photos, video clips or audio
clips.
2. Giving users the option to directly capture images, audio and video clips
using the built-in camera and/or microphone if available.
 Data

There are lots of online RESTful APIs you can make use of when developing this
system. You should consider:

1. The Google Books API

2. LocationIQ

(c) Restaurant Ordering System

Build a digital ordering system for use by a small restaurant. Note that this is a
system that is used by the restaurant staff and not accessed by the general
public. The system should be usable on a tablet or touch screen computer so
keep the interface simple. All menu and ordering data must be stored in a
database.

Testing

You are required to create the following accounts to allow the system to be
tested. All accounts should have the password p455w0rd:
1. waitress (a member of serving staff).
2. waiter (a second member of serving staff).
3. chef

Each of the serving staff should have placed at least one order and the chef
should have flagged at least one order as served.

Stage 1

The core functionality consists of three parts.

Part 1

The system should only be accessible and viewable by registered users. All non-
logged in users to be directed to the login screen.

1. The homepage should display an Add Order link or button.

2. This should take staff to a table select screen with a large button for each
table (assume 10 tables labelled 1-10).
3. Clicking on a table button takes the staff member to the food select
screen. This has big buttons, one per menu item.
4. Clicking on a button adds the item to the order and returns the member of
staff to the same food screen.
5. Once the order has been taken, the member of staff clicks on
the Done button to add the order to the system and return to
the Homepage.

In addition to the data captured through the forms, the database should also
store:
 1. The username of the member of staff logged in.
2. The date and time the order was placed (the Done button was clicked).
3. The order status should be set to placed.

Part 2

The home screen should list all the active orders (those that have a status
of placed or ready).

For each order the following needs to be displayed:

1. Table number.
2. Number of places (the number of meals ordered).
3. Time of order (but not the date)
4. Status (see above)

Part 3

The Homepage should also have a Kitchen button or link. This displays

summaries of all the orders with a status of placed. The summary should include:

1. Time the order was placed (oldest at the top).

2. List of items ordered with quantities.
3. A Ready button that sets the order status to ready (and removes it from this
screen).

Stage 2

The intermediate tasks require you to make changes to the functionality:

1. You need to assign staff as either welcome, servers, kitchen or till.

2. Each use can only see orders with a particular status.
3. The workflow should handle every step from the customer's arrival to
payment and departure.
4. The welcome staff assign tables but are prevented from assigning to an
occupied table.

Stage 3

You are required to implement screens that can only be accessed by the
restaurant owner or admin user:

1. An accounts screen that lists all the accounts that are set up on the system
and allows the admin to:
i. Create new accounts (there should not be a self-registration option).
ii. A dropdown list that specifies the user role, this can be used to assign
roles to users.
2. A menu screen that lists all the currently available menu items and allows the
admin user to:
i. Hide menu items (so they don't appear on the ordering screen).
 ii. Remove menu items (delete completely).
iii. Add new items to the menu.

Extras

In some assignment briefs you are given marks for the appropriate use of media
and using sensors built into the user's device.

Sensors

In some assignment briefs you are given marks for the appropriate use of
sensors and sensor data. You should be implementing:

1. When prompted for a photo, the admin user should be given access to the
device camera (if available).

Media

In the requirements listed above you need to provide the user with the ability to
upload photos. For the extra media marks you will need to expand this by:

1. Providing the user with the choice of uploading photos, video clips or audio
clips.
2. Giving users the option to directly capture images, audio and video clips
using the built-in camera and/or microphone if available.

Data

There are lots of online RESTful APIs you can make use of when developing this
system. You should consider:

1. Spoonacular
2. LocationIQ

Programming Language and Framework

You are free to use any programming language and framework of your choice for
this coursework. However, you are recommended to choose the language that you
have already learned so that you can enhance your skills and learn new ones as you
develop you system.

If you lack the skills needed, you are required to take to learn them on your own. Be
prepared to spend a lot more self-learning time for this module. You are required to
use Test Harness and Distributed Version Control System to achieve higher grade.

Group Element
The Group Element is worth 10% of your final grade and every member of your
group will receive the same mark.
In Week 6 or 7 of the module, you and your group members are required to
demonstrate your product features. You are required to schedule a time with the
lecture for the demonstration.

Individual Element
Individual Element is worth 40% of your final grade. You are expected to write your
own, individual reflective report without collusion with other members of your group.
The report must be around 2500 words. You are only allowed to go above or below
this word count by 10% otherwise marks may be deducted. Also include appropriate
evidence of your work such as charts, logs and screen shots in your report.

Your report will be assessed based on the first four aspects in the grading rubric.
You are advised to refer the Grading Rubric as your guide when you work on this
report. Substantive critical analysis and application of knowledge and understanding
in relation to the experience you gained are expected to achieve higher grades.

This report must be submitted via TurnItIn before 16:00 on the Due Date mentioned
in page 1.
302CEM Grading Rubric

0–2 3–4 5–6 7-8 9 – 10

Agile Limited Demonstrate Demonstrate an Detailed understanding of how Detailed analysis of how agile
Processes understanding and understanding and understanding of how agile agile methodologies are used to methodologies are used to
application of agile application of basic methodologies are used to improve software quality. improve software quality.
15% methodologies. agile approaches. improve software quality. Strong evidence of agile Excellent evidence of agile
No evidence of agile Minimal evidence of Reasonable evidence of processes and good agile processes and agile estimation
process practiced. agile processes agile processes practiced. estimation practiced. practised.
practiced.

Team Poor understanding Basic understanding of A clear understanding of Detailed understanding of how Detailed analysis of how agile
Dynamics of agile team how agile team how agile team dynamics agile team dynamics impacts team dynamics affected the
dynamics. dynamics impacted impacted the development the development process development process efficiency.
5% No evidence of agile the development process efficiency. efficiency. Exemplary evidence of agile
team dynamics. process. Reasonable evidence of Strong evidence of agile team team dynamics.
Minimal evidence of good agile team dynamics. dynamics.
agile team dynamics.

Version Poor understanding Basic understanding A clear understanding of Detailed understanding a range Detailed analysis and reflection
Control of the role of version of how version control the key features of version of features that supports on how advanced distributed
control. helps to improve code control tools and how they distributed code development. development improved code
10% No evidence that quality. improve code quality. Evidence of some branching quality.
version control was Minimal version Reasonable version commit strategy and code review. Evidence of good branching
used. commit evidence. evidence. strategy and code review.

Automated Poor explanation Basic understanding A clear understanding of Detailed understanding and Detailed analysis and evidence
Testing of automated testing of how automated TDD and how this fitted into evidence of good TDD of mature TDD implementation.
techniques. testing improves the chosen workflow. implementation. Detailed analysis showing how
10%
No evidence of code quality. Reasonable Test Scripts Detail understanding of how CI and continuous deployment
TDD. Minimal evidence of evidence. continuous integration (CI) has (CD) have supported the agile
TDD. supported the agile development.
development.

The Product Simple product that Simple functional Product demonstrates a The product demonstrates The product demonstrates
(Group) does not implement product demonstrated. useful range of advanced functionality. advanced functionality and
core functionality. functionality. hosted on the Cloud.
10%