INF2001

Introduction to Software Engineering

Milestone 3:
Design, Test Plan & Prototype
for Workload Management System
Prepared by

Team’s Name: Team Titanic

Randy Cheang Yi Ping 2201708
Tham Yu Xuan, Carment 2201318
Lim Michelle Marie Aliling 2202364
Koh Ming Yi 2201655
Seow Yu Hern Ethan 2201781

Lab Group: P9 Group 5

Github handle: Randy:Randydom99
MingYi : 2201656
Marie :
soobdoobers42
Ethan : CodeXTF2
Carment :
Carment14tham
Date: 25/11/2023
Test Plan & Prototype

Table of Contents
1 Introduction......................................................................................................................................3
1.1 References and Acknowledgments...........................................................................................3
2 Software Design............................................................................................................................... 4
2.1 Architecture Design.................................................................................................................. 4
2.2 Detailed Design........................................................................................................................ 5
2.2.1 Strategy Pattern................................................................................................................6
2.2.2 Observer Pattern.............................................................................................................. 6
3 Testing............................................................................................................................................... 8
3.1 Black Box Testing.....................................................................................................................8
3.2 White Box Testing.................................................................................................................. 10
4 Project Prototype & Wireframe................................................................................................... 14
5 Project Management..................................................................................................................... 21

P9-5 Page 2
Test Plan & Prototype

1 Introduction
The goal of this report is to provide the project's design, test plan, and prototype. Details such as
architecture design, detailed design, black box testing, white box testing, project prototype, and
wireframes will be included in this report to provide a clearer picture of the overall design of the
website as well as documentation of the testing done on the website.

The primary goal of the web application is to provide an overview of the company's personnel
strength in order to reduce misunderstanding and to assign balanced duties to all crew members in
order to avoid over-allocation of labour, as well as to encourage and promote a work-life balance
schedule for the team.

1.1 References and Acknowledgments

[1] “MVC design pattern,” GeeksforGeeks, https://www.geeksforgeeks.org/mvc-design-pattern/

(accessed Nov. 25, 2023).
[2] Codecademy, “MVC: Model, view, Controller,” Codecademy,
https://www.codecademy.com/article/mvc (accessed Nov. 25, 2023).
[3] S. Kumar, “Observer pattern: Set 1 (introduction),” GeeksforGeeks,
https://www.geeksforgeeks.org/observer-pattern-set-1-introduction/ (accessed Nov. 25, 2023).
[4] S. Kumar, “Strategy pattern: Set 1 (introduction),” GeeksforGeeks,
https://www.geeksforgeeks.org/strategy-pattern-set-1/ (accessed Nov. 25, 2023).
[5] V. Walker, “14 software architecture design patterns to know,” Enable Architect,
https://www.redhat.com/architect/14-software-architecture-patterns (accessed Nov. 25, 2023).
[6] S. Rahman, “The 3 types of design patterns all developers should know (with code examples of
each),” freeCodeCamp.org,
https://www.freecodecamp.org/news/the-basic-design-patterns-all-developers-need-to-know/
(accessed Nov. 25, 2023).
[7] L. Singla, “What’s a software design pattern? (+7 most popular patterns),” Insights - Web and
Mobile Development Services and Solutions,
https://www.netsolutions.com/insights/software-design-pattern/ (accessed Nov. 25, 2023).

P9-5 Page 3
Test Plan & Prototype

2 Software Design
This section of the report will explain the rationale behind the chosen Architecture Design and
Detailed Design chosen. It will also include the relevant diagrams that accompany the explanation
for each selected pattern.

2.1 Architecture Design

For the Architecture design, Model-View-Controller (MVC) pattern was chosen for the project.
This pattern is used in interactive applications that require the incorporation of human-computer
interactions in a flexible manner which is suitable for the workload management system of the
project. With the usage of this pattern in the system, it would greatly aid in the frequent interactions
of employees and managers while they are accessing the system to view or edit any necessary
information.

The pattern was selected as it breaks down the applications into 3 components that are handled
separately. The 3 main components consist of Model, Controller and View. Model includes
domain-specific knowledge which is often linked to a database. Additionally, models can be linked
to multiple views. Controller controls the flow of information between the model and the view.
Lastly, View presents the data to the user, it also enables user interaction but does not perform any
processing.

Each main component handles the system’s input, process and output individually which helps in
maintenance as well as troubleshooting whenever there is a fault as it would be easier to identify the
location of the issue. Furthermore, it allows the developers to work simultaneously on the 3
components and is easy to manage due to the component being less dependent on one another
during the function of the application.

Using the MVC pattern, the draft diagram was drawn with the flow of data for the project in mind
as shown below in Figure 1. Starting from the View where the data is presented to the user, data
such as the website User Interface (UI), Account display or Schedule Display can be displayed for
the user for viewing. If the user wants to view specific data, for example the ticket information, this
request will be sent to the controller which is used for ticket control. The controller would also
request if any user interaction is required before proceeding to request for the information. Then the
controller would update the model which is linked to the workload management database to retrieve
the ticket information before sending the data back to view for the user to be able to see the ticket
information.

P9-5 Page 4
Test Plan & Prototype

Fig 1. MVC Pattern Draft Diagram

With the reference from the draft diagram model and the concept of the model is then applied to the
project component diagram as seen in Figure 2 below. The diagram is created with 4 views, 4
controllers and lastly only 1 model. All 4 views are linked to both to their respective controllers and
share 1 model.

Fig 2. MVC Pattern on Component Diagram

2.2 Detailed Design

In terms of the Detailed Design, the possible design patterns that were chosen are: Strategy Design
Pattern and Observer Design Pattern which are categorised under the Behavioural Pattern group.

Strategy Pattern allows an object, at runtime, to swap between the various encapsulated algorithms
and behaviors. Strategy pattern enables different algorithms to be tested without affecting the
overall behavior of the code. Furthermore, it delegates the algorithm’s behavior to one of its
enclosed strategies.

Observer Pattern allows a subject (object) to link to its observers (dependents) in a one-to-many
pattern wherein changes made to Observers would have the subject be notified of the state changes.
Additionally, it allows for loosely coupled design between objects, making it flexible to changes
when necessary. This will be helpful in event-driven programming such as the schedule notification
for Crew members and Managers.

P9-5 Page 5
Test Plan & Prototype

2.2.1 Strategy Pattern

Intent
To provide a flexible way to choose different scheduling algorithms at runtime by encapsulating
each scheduling algorithm into a separate class, the system can switch between strategies as
required.

Applicability
The pattern is applicable in the following ways:

- when the system needs to schedule voyages during peak seasons using various algorithms
- when the system needs to schedule less ferries during off-peak seasons
- when the system might need to modify schedule of Users’ preferred schedule (valid only for
2 weeks in advance)

UML Diagram

Fig 3. UML Diagram for Strategy Pattern

2.2.2 Observer Pattern

Intent
To define a one-to-many dependency between objects so that when an object state changes, all
relevant dependencies connected to it are automatically notified and updated.

Applicability
The pattern is applicable in the following ways:

- when abstraction as one dependent on the other, encapsulate them allows for independent
variety and reusability
- when object change requires updating changes to other dependent objects of undetermined
size
- when objects are not tightly coupled, objects should be able to notify other objects without
assumptions

UML Diagram

P9-5 Page 6
Test Plan & Prototype

Fig 4. UML Diagram for Observer Pattern

P9-5 Page 7
Test Plan & Prototype

3 Testing
This section of the report details methods for each testing; Black Box and White Box as well as the
justification of the chosen method for each testing.

3.1 Black Box Testing

The Black Box testing will be conducted based on UC-2, Task Allocation.

3.1.1 Decision Tables

Testing the scheduling of the company's resources (ferries and employees) for a voyage job.

Table I. Decision Tables for Scheduling

Causes Values

C1 Ferry is free for Y/N N N Y Y

voyage

C2 Employee is free for Y/N N Y N Y

voyage

Effects

E1 No ferry or employee x
is assigned

E2 Ferry is assigned to x
voyage, missing
employee

E3 Employee is assigned x
to voyage, missing
ferry

E4 Employee and Ferry x

is assigned to voyage

P9-5 Page 8
Test Plan & Prototype

The causes for the decision table are dependent on whether the two variables ferry and employee
are free as they will have to be allocated to jobs at the discretion of the manager.

They will be 4 different outcomes when there is a job allocation

1) No ferry or employee is assigned
2) Ferry is assigned to voyage but missing employee
3) Employee is assigned to voyage, missing ferry
4) Employee and Ferry is assigned to voyage

Ultimately, only the 4th outcome will be considered as a successful use case, whereas the rest of the
outcomes will require further allocations from the manager to complete the task scheduling.

3.1.2 Test Cases

Test Case #1
Test Test Case Pre-Con Test Steps Test Data Expect Actual Pass
Scenario ditions ed Result /Fail
Result

Check Check if Resources 1) Ensure the Employee Allocat Allocati Pass

schedulin resources must not resources are free name : ion of on
g can be be 2) Select specific Jack job is success
functional assigned occupied resources Status : success ful
ity to jobs with other (ferries/employees Free ful
jobs ) to allocate jobs Ferry ID :
3) Allocate jobs 14
based on time and Status :
date Free

Test Case #2
Test Test Case Pre-Con Test Steps Test Data Expect Actual Pass
Scenario ditions ed Result /Fail
Result

Check Check if Resources 1) Ensure the Employee Allocat Allocati Pass

schedulin resources must not resources are free name : ion of on
g can be be 2) Select specific John job is unsucce
functional assigned occupied resources Status : unsucc ssful
ity to jobs with other (ferries/employees Occupied essful
jobs ) to allocate jobs Ferry ID :
3) Allocate jobs 15
based on time and Status :
date Free

P9-5 Page 9
Test Plan & Prototype

Test Case #3
Test Test Case Pre-Con Test Steps Test Data Expect Actual Pass
Scenario ditions ed Result /Fail
Result

Check Check if Resources 1) Ensure the Employee Allocat Allocati Pass

schedulin resources must not resources are free name : ion of on
g can be be 2) Select specific Bob job is unsucce
functional assigned occupied resources Status : unsucc ssful
ity to jobs with other (ferries/employees Free essful
jobs ) to allocate jobs Ferry ID :
3) Allocate jobs 16
based on time and Status :
date Occupied

Test Case #4
Test Test Case Pre-Con Test Steps Test Data Expect Actual Pass
Scenario ditions ed Result /Fail
Result

Check Check if Resources 1) Ensure the Employee Allocat Allocati Pass

schedulin resources must not resources are free name : ion of on
g can be be 2) Select specific Peter job is unsucce
functional assigned occupied resources Status : unsucc ssful
ity to jobs with other (ferries/employees Occupied essful
jobs ) to allocate jobs Ferry ID :
3) Allocate jobs 17
based on time and Status :
date Occupied

3.2 White Box Testing

The white box testing will be conducted based on UC-3, Accepting/Rejecting Schedule change.

3.2.1 Pseudocode

The pseudocode shown in the table below represents the function ticketResponse where a manager
either approves or rejects an employee's ticket for leave or request for shift changes. This function
contains a total of 9 operations, 1 User Input Operation, 3 Conditional Operations, 2 Status Update
Operations and 3 Print Operations, which we will be using to determine the number of nodes for our
CFG.

P9-5 Page 10
Test Plan & Prototype

1 string ticketResponse() {
2 User Input (choice):
3 choice = GetUserInput()

4 If choice is 1 Then
5 ticket.setStatus(TicketStatus.APPROVED)
6 Print(“Ticket approved successfully.”)
7 Else If choice is 2 Then
8 ticket.setStatus(TicketStatus.REJECTED)
9 Print(“Ticket rejected.”)
10 Else
11 Print(“Invalid choice. Please try again.”)
}
12 end

3.2.2 Control Flow Graph (CFG)

Fig 5. Control Flow Diagram (CFG) for the tickerResponse() function

We have made a Control Flow Graph (CFG) of the function ticketResponse() which shows the execution
logic. This function is based on the use case UC-3, Accepting/Rejecting Schedule change. With this CFG, we
are able to determine the basis paths of the function, as well as determining the test specifications and test
cases.

3.2.3 Cyclomatic Complexity

To calculate the Cyclomatic Complexity, we will use the following formula

M = E - N + 2P

P9-5 Page 11
Test Plan & Prototype
Where M = Cyclomatic Complexity, E = number of edges in the Control Flow Graph, N = number of nodes
in the control flow graph, P = number of connected components
M = 12 - 11 + 2(1)
M=3
Therefore the Cyclomatic Complexity of the function ticketResponse() is 3.

3.2.4 Basis Paths

The diagrams below shows the amount of basis paths that we have identified with the help of the Control
Flow Diagram (CFG). The number of basis paths identified matches with the complexity of the
ticketResponse() function.

Fig 6. Basis Paths of ticketResponse function

Basis Path 1: 1 → 2 → 3 → 5 → 7 → 9 → 11
Basis Path 2: 1 → 2 → 3 → 6 → 8 → 10 → 11
Basis Path 3: 1 → 2 → 4 → 11

To determine our basis paths, we picked “Basis Path 1” to be referenced as our Base Line path. We then
back-tracked “Basis-Path 1” until we reached decision node 3 where we flipped it to the False edge and
continued on the next path , resulting in “Basis Path 2”. To determine “Basis Path 3”, we back-tracked “Basis
Path 1” again but this time to decision node 2, where we flipped it to the False edge and continued on the
next path, resulting in “Basis Path 3”.

3.2.5 Test Cases

P9-5 Page 12
Test Plan & Prototype

Test Specifications:

Requirement #1: Manager must approve ticket request

Requirement #2: Manager must reject ticket request
Requirement #3: Manager must not respond to the ticket request

The following test cases show the flow and total branch coverage of the Basis Paths shown above. The Test
Cases order corresponds to the Basis Paths order.

Test Case #1
Ticket type: “Leave Request”
Response: ‘Approved’
Status: ‘Completed’

Test Case #2
Ticket type: “Leave Request”
Response: ‘Rejected’
Status: ‘Completed’

Test Case #3
Ticket type: “Leave Request”
Response: ‘NIL’
Status: ‘Pending Response’

P9-5 Page 13
Test Plan & Prototype

4 Project Prototype & Wireframe

The web-based task management system aims to streamline the personnel management and
scheduling processes of ferry staff. The application features a user-friendly and mobile accessible
interface in the form of a web application, and follows a role-based access control structure. It is
separated into 3 sets of user interfaces: Admin, Manager and Staff, which are used when logged into
users of the respective roles. Users have a personal notification area where they can receive
notifications relevant to their job functions.

When a user logs in as a Staff, they are shown the main staff dashboard page, which shows their
latest assigned schedule. They have access to a page to update a set of proposed schedules that they
are available to work, and pages to submit leave/rescheduling tickets and incident reports.

Fig 7. Dashboard for normal Staff User

P9-5 Page 14
Test Plan & Prototype

Fig 8. Staff is able to adjust their task schedules

Fig 9. Staff can apply leave and others

P9-5 Page 15
Test Plan & Prototype

Fig 10. Staffs are able to report issues that arise

Fig 11. Staffs are able to edit their work schedule

P9-5 Page 16
Test Plan & Prototype

Fig 12. Staffs can acknowledge their assigned schedule or request a change

When logged in as a Manager, the main dashboard page shows a calendar containing information
for each day, such as ferry locations and work roster for the day. They also have access to a search
bar that allows them to search for employees by name or employee ID and view their work
schedule. Managers also receive tickets and reports from employees, and have a page to view,
accept and reject tickets for leave or rescheduling, as well as incident reports. Managers are in
charge of scheduling, and use a page to create voyages, and assign ferries and staff members to each
voyage. They can also view the maintenance schedules for all ferries.

P9-5 Page 17
Test Plan & Prototype

Fig 13. Dashboard for Manager User

Fig 14. Voyage Creation

P9-5 Page 18
Test Plan & Prototype

Fig 15. Ferry Maintenance

When logged in as an Administrator, the only feature accessible is account management, which
allows for account creation, modification and deletion. This is done for security purposes to enforce
separation of roles; an administrative account should be used for administrative purposes only and
not for day to day tasks. minimize exposure of privileged credentials.

Fig 16. User Management

P9-5 Page 19
Test Plan & Prototype

A standard login and password reset page is present.

Fig 17. Login

Fig 18. Password Reset

P9-5 Page 20
Test Plan & Prototype

5 Project Management
The Gantt Chart, Fig. 19 and 20 that is displayed below will only show week 7 along with the task
allocations that are allocated. There have been no overruns in the project and all tasks have been
completed within the given timeframe.

Fig 19. Gantt Chart (Top)

P9-5 Page 21
Test Plan & Prototype

Fig 20. Gantt Chart (Bottom)

P9-5 Page 22