Assessment Brief

Programme: MSc Computing and Technology

Module Code: LD7092

Module Title: Principles of Software Engineering

Distributed on: Via Blackboard; briefing in lecture.

Submission Time
To be submitted by 16:00 GMT on [21 Jan 2025]
and Date:

Word Limit: 4,000 words

Weighting This coursework accounts for 100% of the total mark for this module

Submission of
Electronic Management of Assessment (EMA): Please note if your assignment is
Assessment
submitted electronically, it will be submitted online via Turnitin by the given deadline.
You will find a Turnitin link on the module’s eLP site.

It is your responsibility to ensure that your assignment arrives before the submission
deadline stated above. See the University policy on late submission of work.

Please note that assignments are subject to anonymous marking.

Instructions on Assessment:

General Information

This assignment constitutes 100% towards the final mark for this module. Any queries relating to this
assignment should be directed to module leader, [email protected]

Type of the submission required.

This is an INDIVIDUAL piece of work divided into two tasks as follows.

1. Practical Solution Prototype (50%)

Design and development of a program prototype solution using OOP language such as Java
on the given case study. This activity assesses module learning outcomes 1, 2 & 5. (2000
words)
2. Critical Discussion (50%)
Critical discussion of some issues relating to Software Engineering. This activity assesses
module learning outcomes 3 & 4. (2000 words)

Assignment Details:

Case Study: Food Heaven Restaurant Management System (FHRMS)

Food Heaven Restaurant (FHRMS) is a traditional American restaurant based in London with a team of
high-quality chefs who prepare delicious American cuisines for the customers. In recent time, FHRMS
owner decided to develop a new information system to manage the restaurant and serve their patrons
in efficient way. You are required to design and develop a user-friendly, desktop application to assist
FHRMS staff including chefs, waiters and managers in managing the restaurant inventory (tables,
chairs, dishes, glasses, etc.), food and beverages ingredient, and serving American cuisines for
customers using an advanced Restaurant Management System. The new system has to be designed in
an appropriate way to enable the restaurant staff and patrons to access the system and perform
different activities such as: the chefs to manage the F&B ingredient, make sure they are available, and
prepare the food orders for customers; the waiters to take the orders from customers and serve them;
Page 1 of 6
Assessment Brief

the manager to record all orders, prepare the bill and manage users including chefs and waiters
records.

The FHRMS system should be able to manage F&B ingredient records, automatic send reminders to
chefs for purchasing ingredients from the suppliers, for manager to analysis the sales records and
human resources and much more.

The system should allow registered users to use it only after login. Key features of the FHRMS point-of-
sale system include:

- User friendly GUI based system for staff to use in the restaurant
- Receipt printing, payment collection
- Generate notification detailing items that are low or out of stock
- Inventory record management
- Human resources management
- Food orders records generation and analysis
- Any other relevant services

Task 1: Design and Development (50%, Learning Outcome 1 & 2 & 5)

Using the provided case study, develop a solution from a system analyst’s perspective that includes the
following:

 Produce a Use Case Diagram to model the functional requirements from the scenario narrative.
o Showing actors and the use cases they perform.
o Use inheritance where necessary of both use cases and actors.
o Use of <<includes>> and <<extends>> where necessary.
o Use house style model to document at least two primary use cases.
 Produce a Class Diagram to model the system structure for your potential solution. This should
include:
o Detailed classes with all key variables/attributes and datatypes with access modifiers (private,
public or protected) clearly shown in adherence to encapsulation principle of OOP.
o Procedures or functions with (parameters and their datatypes shown) as well as return type for
the class functions. (see diagram example below)
o Use of class relationships (e.g. dependency association, aggregation, composition and
inheritance).
o An example of class diagram for product ordering system is shown in Figure 1.
 Produce a Sequence Diagram to model functional requirements from the scenario narrative for two
key primary use cases. Decouple as much as possible with Boundary, Control and Entity.
o Showing actors and interacting objects.
o Messages (Methods) calls between objects with parameters and return types were necessary.
o Use of alternatives and loops where necessary.
o An example of sequence diagram is shown in Figure 2.
 Develop the Interfaces using OOP language (Java with NetBeans IDE)
o Document your solution with relevant screenshots and snippets of codes.
o Produce a test plan and test cases.

Page 2 of 6
Assessment Brief

NOTE: The solution is only going to be a prototype of the software architect level, but a skeletal code
should be produced. You do not need to write any advanced level functionality into the methods or
permanent data storage, but you must build and design the Forms (eg, JFrames and JPanels) and link
them to each other with relevant GUI components such as buttons, text fields, labels etc. The program
should be executable (i.e. no compile time errors that prevent it from being executed).

Figure 1, a basic class diagram for product ordering system

Figure 2, an example of detailed sequence diagram

Task 2: Reflection and Critical Evaluation (50%, Learning Outcome 3 & 4)

Page 3 of 6
Assessment Brief

You are required to write a report to address the following topics:

• Using software engineering literature, critically evaluate the Software Development Life Cycle
(SDLC) methodology you have chosen for your solution development with relevant examples from
your work (clarify how you applied it in the various SDLC phases).
• Critically reflect on professional, legal, social, security and ethical issues related to the design and
development of your solution.

This is meant to be a critical discussion and not just a description. Your discussion should not be limited
to your practical system (the prototype), but a discussion of the broader issues involved in the design of
your solution such as the functional requirements, use case documentation, the main classes involved
in the class diagram and sequence diagram with justification of any important design decisions.

Mapping to Programme Goals and Objectives

This assignment will assess the following learning outcomes:

1. Demonstrate critical knowledge and understanding of appropriate software engineering theories,

technologies and methodologies.
2. Ability to apply software engineering knowledge to a complex business challenge or project.
3. Critically reflect on professional, legal, social, security and ethical issues related to the design,
development and use of software in an organisational context.
4. Ability to critically evaluate your Software Engineering skills.
5. Demonstrate problem solving skills in complex situations in the context of the design,
development and use of software solution
6. Ability to critically evaluate the risk assessment methodology to determine appropriate control
objectives for a given organisational scenario.

Module Specific Assessment Criteria and Rubric

The work will be marked out of 100 in line with the University’s marking grades and according to the following
assessment criteria:

Description Marks

Task 1: Practical Solution (50%)

(suggested word limit for this task is 2,000 words)

Use case modelling

 List of functional requirements
 Logical design showing actors and associations including inheritance 10
(generalisation/specialisation) of actors and use cases as appropriate.
 Comprehensive use case documentation using house style.

Class diagram:
 Logical design showing classes and members (functions and procedures with
parameters and return types)
 Efficient design using object-oriented features such as encapsulation,
10
abstraction, inheritance, polymorphism and composition/aggregation where
applicable.
 Documentation of main classes and associations.

Sequence diagram: 10
Page 4 of 6
Assessment Brief

 A logical design showing all objects involved in the use case scenario.
 Messages/Method calls that reflects class diagram structure and
communications.
 Parameters and return types shown.
 Use of design patterns e.g. Model-View-Control model.
 Control structure using alternatives and loops.

Program & Testing:

 A working prototype which includes the interfaces and reflects the system
designs. Use of coding standards and comments.
 Use of OOP principles (e.g. abstraction, inheritance, encapsulation, 20
polymorphism where applicable).
 A comprehensive test plan and cases.
 Documentation of the prototype is essential.

Task 2: Reflection & Critical Discussion (50%)

(suggested word limit for this task is 2,000 words)

Critical evaluation of SDLC and justification of chosen methodology in context of your solution with
20
relevant examples for each phase of SDLC.

Critically reflect on professional, ethical and security issues related to the design, development and use
20
of the software in the given project context.

Citations, references and report structure 10

Total 100

ASSESSMENT REGULATIONS

You are advised to read the guidance for students regarding assessment policies. They are available online
here.

Academic Misconduct

The Assessment Regulations for Taught Awards (ARTA) contain the Regulations and procedures
applying to cheating, plagiarism, the use of Artificial Intelligence (AI) Systems, and other forms of
academic misconduct.

The full policy is available here

You are reminded that plagiarism, collusion, the use of Artificial Intelligence (AI) Systems, and other forms of
academic misconduct, as referred to in the Academic Misconduct procedure of the assessment regulations,
are taken very seriously. Assignments in which evidence of plagiarism or other forms of academic
misconduct is found may receive a mark of zero.

Late submission of work

Where coursework is submitted without approval, after the published hand-in deadline, the following
penalties will apply. For coursework submitted up to 1 working day (24 hours) after the published hand-in
deadline without approval, 10% of the total marks available for the assessment (i.e.100%) shall be
deducted from the assessment mark.

Page 5 of 6
Assessment Brief

For clarity: a late piece of work that would have scored 65%, 55% or 45% had it been handed in on time will
be awarded 55%, 45% or 35% respectively as 10% of the total available marks will have been deducted.

The Penalty does not apply to Pass/Fail Modules, i.e. there will be no penalty for late submission if
assessments on Pass/Fail are submitted up to 1 working day (24 hours) after the published hand-in deadline.

Coursework submitted more than 1 day (24 hours) after the published hand-in deadline without approval
will be marked as zero but will be eligible for referral. The reassessment should where appropriate, and as
determined by the Module Leader, be the same method (e.g. essay) but maybe with a different task (e.g.
different essay title) or with the same task (e.g. the same essay title) as indicated in the Module handbook.
In modules where there is more than one assessment component, Students are not required to complete all
assessment components if an overall Pass Mark (40% UG, 50% PGT) has been achieved.

The only permitted exception will be in cases where the University is prevented from doing so by a PSRB
requirement. In the case of PSRB requirements, a variation order will be required from the regulations.

In modules, where there is more than one assessment component and an overall pass mark has not been
achieved, Students will be eligible for a referral* in the individual failed module and/or not attempted
component(s) of assessment.

These provisions apply to all assessments, including those assessed on a Pass/Fail basis.

The full policy can be found here

Word limits

The word count is to be declared on the front page of your assignment and the assignment cover sheet. The
word count does not include:

****PLEASE CONFIRM WHAT THE WORD COUNT DOES NOT INCLUDE**** e.g. appendices, glossary,
footnotes, tables

Please note, in text citations [e.g. (Smith, 2011)] and direct secondary quotations [e.g. “dib-dab nonsense
analysis” (Smith, 2011 p.123)] are INCLUDED in the word count.

If this word count is falsified, students are reminded that under ARTA this will be regarded as academic
misconduct.

For those assessments where students are required to keep to the word limit, it is proposed that they should
be informed that the marker will stop reading at the point when they judge that the word limit exceeds the
recommended word count by more than 10%. The marker will indicate the point at which they stop reading
on the text.

Students must retain an electronic copy of this assignment (including ALL appendices) and it must
be made available within 24hours of them requesting it be submitted.

The full Word Limit Policy is available here

Page 6 of 6