imsmoothlikebutter / ict2101-2201-team-project-p2-8 Goto Github PK

Confirmed questions to ask:

1. Is the chief the one who allocate and plan workload? (If yes, does officers & leaders submit their availabilities every wed?)
2. Staff = Leaders, Officers. Managers = Chief?
   What's the access level of each role (4 roles given: IT admin, Chief, leaders and officers). Also any difference in access level between site leader and area leader?
   Will reporting be done through the management system? If yes, what is the reporting hierarchy and what does it entails?
3. What can chief see/visualize when overseeing the sites
4. How do you quantify workload? Is it only by raw workhours or can it be base on type of site worked?
5. Do you track standby manpower (E.g Available, Standby, Unavailable, Assigned etc.)
6. Do want the workload management system to track attendance (on the actual day, signing out) like a clock-in, clock-out feature
   Do the system automate last minute change or manager manually changes?
   Who can edit staff's hours?
7. What does point 4 mean: "The manager should be able to view up to three staff availability and any relevant information
   to make the job assignment easier on the job allocation page"

If got spare time ask these:

1. Is "Job Preference" the site they want to work at? (Day to work, shift they want to work, site to work at)
2. Since there are plenty of "X days in advance" features, do you want a reminder system?
3. (Unimportant) Are chiefs' workload included in the system? If yes, Who assign workload for the chiefs?

To prepare ourselves for the upcoming meet with our client, we have perused the initial requirements provided. However some points were ambiguous to us. Thus, we have derived these 10 questions from the aforementioned requirements. Considering the constraint of 10 minutes stipulated by our clients, we decided to carry on with 7 questions which we surmise to be the most important points to address, and 3 more questions lest there is leftover time.

Based on SRS, initial client meeting prototype

https://www.figma.com/file/waFUynejKFHmzf1ULcIGjK/2101-Finalised-Prototype?node-id=6%3A38&t=kvXotQ86QEoA3WT2-1

What do we struggled on?

• Choosing the correct design architecture and patterns. There are abundant of architectures and patterns available, so there was an information overload. Hard to choose the most suitable architecture and patterns.

• Creating a class diagram with the selected architecture and pattern.

• Creating a component diagram with the selected architecture and pattern.

-Creating a sequence diagram for the use cases we decided to use was challenging as we were not 100% sure if we were doing it right.

What can we improve on?

• Clarifying more with the profs regarding the UML diagrams.

• Communicated better as a team as sometimes we can be out of sync.

add individual reflections to M1 report before submission

https://www.figma.com/file/MVrk7pFrvuDUK62jKf5p0n/2101-project?node-id=103%3A4269
Prototype shows Login Screen with Managers Flow and Officer's Flow

https://www.figma.com/file/ysfOKEZgM8aVOrbQCt5B5C/2101-project-(Refined)?node-id=103%3A5933

Based on the prototype feedback:

1. Sites are not an option, they are tenured by the client
2. The calendar only shows 7 day view.
3. Staff should only choose which shift (AM or PM) they prefer

Milestone 2: Software Design Documentation
Weightage: 20%

State Diagram Link: https://drive.google.com/file/d/1DlkdR6UiSj3q28Im_DuHLRyYmcJyS-8D/view?usp=sharing

Stage 1: Concise Problem Definition

• Describe the project using statements in single paragraph

Manager assigns schedule to the staff and assigns backup personnel. Both Manager and staff can view their work schedule, their work hours and their status. Staff can reject schedules assigned to him and also indicate their shift preference to the managers. IT admin is able to add sites, manage staff and manage managers.

Stage 2: Identify the nouns

• Identify Nouns in the informal Description

Manager assigns schedule to the staff and assigns backup personnel. Both Manager and staff can view their work schedule, their work hours and their status. Staff can reject schedules assigned to him and also indicate their shift preference to the managers. IT admin is able to add sites,manage staff and manage managers.

Based on the Project Description, the identified nouns are as follows: (Removed Duplicates)

• Manager
• Staff
• Schedule
• Backup Personnel
• Status
• Work Hours
• Preference
• Sites

The candidate classes are

• Manager
• Staff
• Schedule
• Site
• Preference

The other classses are used as attributes:

• Backup Personnel
• Status
• Work Hours

Stage 3: Remove duplicates, convert to Singular

• Specify Subclass and Candidate Class
• Convert the Candidate class into entities
• Identify services and behaviours (verbs)

Next step would be to identify services and behaviours

Manager assigns schedule to the staff and assigns backup personnel. Both Manager and staff can view their work schedule, their work hours and their status. Staff can reject schedules assigned to him and also indicate their shift preference to the managers. IT admin is able to add sites, manage staff and manage managers.

Below are the identified behaviours:

• Assign Schedule
• Assign backup Personnel
• View work schedule
• Reject schedule
• Indicate shift preference
• Add site
• Add staff members (and managers)

Milestone 3: Final Prototype and Test Plan
Weightage: 20%

Refine Specifications after client meetings on 13 Sep

Functional Requirements

3.2.1 Login Page
3.2.1.1 The system shall display the login page on the user’s screen upon launching of the workload management system.
3.2.1.2 The login page shall display the following fields:
Username and Password
A Login as Staff button
A Login as Manager button
3.2.1.3 The system shall allow the user to input their Username and Password in the provided fields.
3.2.1.4 The system shall allow the user access to their respective Homepages after verifying their credentials by clicking on either Login buttons.

3.2.2 Site Homepage
3.2.2.1 The system shall only display the calendar in a 7 days view.
3.2.2.2 The system shall only display two 12 hour slots each day.
3.2.2.3 The system shall display up to 3 available staff sorted by the least number of hours worked.
3.2.2.4 The system shall also display the number of hours worked for the 3 available staff.
3.2.2.4 The system shall allow the Manager to click on each 12 hour slot to allocate workload.
3.2.2.5 The system shall highlight any rejected assignments.
3.2.2.6 The system shall only display staff under their jurisdiction.
3.2.2.7 The system shall display all assigned staff for each slot.
3.2.2.8 The system shall display 2 standby personnel for each slot.
3.2.2.9 The system shall display all staffs’ availability for the week.
3.2.2.10 The system shall display all staffs’ shift preferences for the week.
3.2.2.10 The Site Homepage shall only be accessible to Managers.

3.2.2.12 The system shall display

3.2.3 Staff Homepage
3.2.3.1 The system shall only display the calendar in a 7 days view.
3.2.3.2 The system shall only display two 12 hour slots each day.
3.2.3.3 The system shall allow staff to view all assigned workload for the week.
3.2.3.4 The system shall allow staff to submit their availability for the month.
3.2.3.5 The system shall allow staff to reject an assigned workload.
3.2.3.6 The system shall allow staff to submit their shift preference for the week.
3.2.3.7 The system shall allow staff to edit their availability 5 weeks ahead of time.

3.2.4 IT Admin Homepage
3.2.4.1 The system shall allow the IT Admin to add staff.
3.2.4.2 The system shall allow the IT Admin to remove staff.
3.2.4.3 The system shall allow the IT Admin to view the system in Manager View.
3.2.4.4 The system shall allow the IT Admin to view the system in Staff View.
3.2.4.4 The system shall allow the IT Admin to add security sites.
3.2.4.5 The system shall allow the IT Admin to remove security sites.

3.2.5 Manager Homepage
3.2.5.1 The system shall allow Manager to select from all currently tenured sites.
3.2.5.2 The system shall notify the Manager once a site has been fully assigned.
3.2.5.3 The system shall notify the Manager if a site has not been fully assigned.
3.2.5.4 The system shall notify the Manager should any Staff reject their allocated workload.
3.2.5.5 The system shall display the top 3 staff with the lowest workload.
3.2.5.6 The system shall display all staff that exceed 40 hours of workload per week.

Non-functional Requirements

NFR1: The system shall be accessible from all devices that support a Web browser.
NFR2: The system shall be scalable for future addition of features.
NFR3: The system shall support all browsers.
NFR4: The system shall only take less than 1 second to load 78 staffs’ data.
NFR5: The system must perform without failures 95% of use cases.
NFR6: The system must be available to all users 99% of the time every week.

https://docs.google.com/document/d/130ONAfHYOnkxjGpS5Siy8ott5oub5-qh5nL45faCOE8/edit
Link to document with minutes taken during the meeting with our client

During the meeting, we have cleared many doubts that we initially has. However, as the project progresses, more uncertainties could arise that could find us revising points covered in the meeting.

The client had stated his requirements, and we have noticed that certain points has deviated from his initial requirements which are to be expected. This client meeting has provided us with valuable insight with which we can then do need finding & analysis. Afterwards we could then draw up Functional Requirements; Non-functional Requirements; Use Case Model & Use Case Description; a project estimation of the size and effort required. The resulting documentation could then be used to clarify further with our client while, at the same time, build rapport with them.

Use case chosen for White Box Testing: Use Case 4 (Assign Job)
White Box Testing CFG Link: https://drive.google.com/file/d/1DlkdR6UiSj3q28Im_DuHLRyYmcJyS-8D/view?usp=sharing

MARCUS OH HAN YAO
what i have learn form milestone3 is that the importance of blackbox and whitebox testing like for blackbox testing it help us to get full coverage of end cases so that we would not miss out on test cases that would lead to an error on our application.For whitebox testing it helps us inspect and verify the internal workings of the application code with the use of determining the CFG and basis path.

If I were to do things differently, I would create more whitebox test cases to show a more detailed view of the different code, CFG, and basis path, as well as to have consider the different use cases.we as a team could have consider developing the webapp so that it could give a better understanding and overall feel of the project even deeper.

LEE HONG SHEEN
I learned from milestone 3 that testing is an important aspect in software development. I learned the different applications of testing such as black box and white box testing, and how it is important to debug as many errors as possible. I also learned that no matter how many errors we try to debug, it is impossible to cover all of the errors.

If I were to do things differently, I would consider more test cases in the black box testing to be able to cover more errors. I feel that it is important to be able to solve these errors as early as possible to be able to provide a complete working software product for the clients.

TOH ZHENG HUI
For milestone 3, I was tasked with creating the prototype for the web app. Since there was no coding for the prototype, it has to be done with figma. I have never used figma before. The learning curve for figma was steep at first. However, subsequent hours using figma were easier. I realised that figma is crucial in web development projects because it is a powerful tool for creating wireframes and prototypes. Both are essential in building rapport with clients and for them to build confidence that we (the team) are clear on what they (the clients) want the end product to look like.

If I were to do things differently, I would look at the requirements more thoroughly and check with the clients (if not possible, check with our client minute) if there were requirements or features that I may have not done well.

MUHAMMAD ISMAEL OSMAN
I have learnt of the importance of conducting tests to verify the performance of the product against our requirements. Blackbox testing only takes in the input and returns and output without being concerned with how the code works. It allows us to verify that the inputs match the expected outputs that we designed while Whitebox testing has us testing every decision with the Complexity Factor Graph and Basis paths. It ensures that we go through every decision in the code. The advantages of conducting both tests is that we would be able to compliment each other and overcome the disadvantages of each testing method, overall giving us a better coverage of testing.

If I were to do things differently I would like to conduct more in-depth testing to further test the full capabilities of the product. This would ensure that the web app has better coverage in reliability and accuracy. I would also like to try coding the actual product if given more time and weightage. I feel that developing the product while following the chosen architecture and design pattern would be a new and important learning experience.

2. What could be improved? Eg. Team Dynamics, Team Management, Task allocation and management

• Need actively update each other
• Skipping too many steps to produce models
• Better communication, more face-to-face meetings
• Better management of Github Project Board

2101 UseCasePoints.xlsx

Added

1. What went well in Milestone 1?

• Everyone has common understanding of requirements
• Everyone is attentive for group meeting
• Deadlines are met on time

Create Component Class from the Entity Class Diagram that is provided.

Create a database Component for the system

Modals

• Staff
• Manager
• Preference
• Schedule
• Sites

Controllers

• StaffController
• ScheduleController
• PreferenceController
• SiteController

Views

• ViewStaff
• ViewPreference
• ViewSchedule
• ViewSites
• ManageSchedules

Additional Components

• Database
• External notification System
• Observer

Step 2: Create Interfaces to link the Components together

IStaff - Links Staff to Staff Controller
ISchedule - Links Schedule to Schedule Controller
IPreference- Links Preference to Preference Controller
ISite- Links Site to Site Controller

https://app.diagrams.net/#G12UAuTgTEkSQRJ0jT9yAXVKVyjGnD_Rct

Step 1: Identify the main use cases

• Use case 1: IT-Admin adds a new site to the system
• Use case 4: Manager assigns Staff to the Work Schedule
• Use case 5: Staff rejects the job assigned to him/her
• Use case 8: Staff adds their availability

Step 2: Plan out the sequence diagrams

Use case 1:

ITAdmin - SitesUI - SiteController - SiteDB : Retrieve/ Add / Update / Delete Sites

Alternate Scenarios:

• Cannot Connect to DB
• Cannot save changes to DB
• Cannot show updated sites

Use case 4:

Manager - ScheduleUI - ScheduleController - DB : Get Sites
Manager - ScheduleUI - ScheduleController - DB : Assign Jobs (Select Name, Shift)

Alternate Scenarios:

• Display Work Flow

Use case 5:

System - StaffScheduleController - StaffScheduleUI - Staff: Display Schedule for staff
Staff - ScheduleUI - ScheduleController - StaffDB: Reject Job

Alternate Scenarios:

• No shift for staff to reject
• Staff cancels his rejection

Use case 8:

ScheduleDB - StaffScheduleController - StaffScheduleUI - Staff : Display Schedule for staff
Staff - StaffScheduleUI - StaffScheduleController - ScheduleDB: State Availability

Alternate Scenarios:

• No shift for the staff to indicate preference
• Staff cancels their preference

Step 3: Construct the sequence diagrams with descriptions

https://app.diagrams.net/#G1Lbdk2KnIRuRZI7yAnA_nobVh6tZ7Y3KJ

https://drive.google.com/file/d/12iPctS86c5ILM2T0JnWIUUBOEAHLAWy5/view?usp=sharing

Create a use case based on the requirement specifications
Assumptions:
20 Sep: This diagram takes into consideration possible future expansions and features, (Eg, allowing IT Admins to add sites.)
20 Sep: Draft allocation for Thursday morning is done ON PAPER (NOT TRACKED), only the allocation for MONDAY is done IN SYSTEM.
20 Sep: Area Leader, chief are the managers. Site Leader, Security Officers are the staff members

Milestone 1: Software Development Plan & Specification Report
Weightage: 20%

Based on the 10 common architecture patterns

Layered pattern : Could be suitable for our project
Client-server pattern : Not suitable due to difficulty to meet scaling users.
Master-slave pattern: Not suitable as there are many asynchronous requests in the application, which will disrupt the system.
Pipe-filter pattern: Not suitable as it is too complex to scale upwards
Broker Pattern: Not suitable as it requires standardization
Peer-to-peer pattern: Not suitable due to security issues
Event-bus pattern: Could lead to issues during scaling if all messages are sent through the event bus, hence not suitable
Model-view-controller pattern : Suitable as there are different users (Manager and Staff), able to split into different views
Blackboard pattern: Not suitable as there is no common data
Interpreter pattern: Not suitable due to performance issues

Ultimately, we decided to use MVC for our project.

Use of Observer patterns in the project

Craft the Architecture diagram using MVC and Observer design patterns

https://app.diagrams.net/#G12UAuTgTEkSQRJ0jT9yAXVKVyjGnD_Rct

M1 Feedback (Based on the marking report)

10/10/2022 M1 Feedback

1. Software Requirement Specifications

Many requirements are correct
Most requirements are detailed, meet the 7 traits of good requirements
Use case diagram missing database
Incorrect extend association

2.Project estimation- Size, Effort, Duration

Incorrect UCP Size
Correct Measurement of UCP effort
No Duration Estimation
M2 and M3 schedules

3. Team Management

Missing SDLC
All tasks are well-assigned
Update all tasks
Add content to Description

4. Report Format and Writing

Follow IEEE standard
Clear Text and Images
Logically organized and formatted throughout the report

Based on the Use case diagram, create the use case description to have a rough estimation of the requirements

Discuss client meeting minute and refine requirements

https://docs.google.com/spreadsheets/d/1d7mpykGTZXv5l7LwbL2e0UC8Ew_kGdumK68DQf9-oFA/edit?usp=sharing

3. What will we commit to improve in the next milestone?

• Better communication with team, describe intentions clearly
• Discuss details about diagrams with the team
• Ask more questions, strive to improve the diagrams and eliminate more assumptions about the project.

Step 1: Create attributes based on classes identified

• Manager: Name, Email, Mobile, Site
• Staff: Name, Email, Mobile, Site, Work_Hours
• Schedule: Staff_Name, Backup_Name, Status, Date, Period
• Site: Name, Location
• Preference: Staff_Name, Date, Period

For Schedule, period indicates the AM/ PM shift.
These attributes form the inital class diagram.

Step 2: Form Relationship between classes

Create Initial Class Diagram without forming Control Classes

-Staff and Manager are assigned to Sites

When sites are removed, staff and member entities remain (Aggregation)
A site is assigned to any number of staff/managers, but a staff/manager is assigned to only 1 site

• Preferences are assigned by Staff

When staff is removed, the preferences are removed as well (Composition)
Staff can have different preferences (Over different periods of time), but each preference is assigned to only 1 staff member

-Staff are assigned to Schedules

When schedules are removed, the staff members remain (Aggregation)
Both main staff and Backup staff are part of the schedules, hence multiple relationships
A staff can have any number of schedules assigned, including backup, but each schedule is assigned to one personnel and backup

https://app.diagrams.net/#G1yX7P23ABK0JxfsaW1YuOvZTpr7_sURzE

Assumption: Staff / Managers are only assigned to 1 site.

Step 3: Create Control Classes by splitting the Entity Classes

Convert the initial class diagram into an Entity class diagram

IT-admin uses the system to enter locations for the staff and manager, hence requiring a siteControl
Staff uses the system to state their available dates, hence requiring a preferenceControl
Managers use the system to schedule the dates for the staff, hence requiring a scheduleControl

IT-admin uses the system to register new Staff and Managers, hence require userRegistrationControl
System notifies the manager/staff through their mobile/ email, hence requires SMSserver and EmailServer

1. Schedule Control

addSchedule() - Allows creating of schedule
showLowestHours() - Shows lowest hours of top three staff
getAllPreference() - retrieve preffered date of the staff
changeStaff() - changes staff assigned to the schedule
changeBackup() - changes backup personnel
notifyStaff() - notifies specified staff once their schedule is confirmed

2. Site Control

deleteLocation() - remove location from the system
addLocation() - adds new site to the system

3. Preference Control

addPreference() - Allows Staff to indicate their preferred date
notifyManager() - Notifies Manager that the job is rejected (Assuming staff rejects job)
rejectJob() - Allows staff to reject the job assigned to them.

4. UserRegistrationControl

createUser() - creates the managers/staff users for the system
validateName() /validateEmail()/ validateMobile() - validates the fields for the users

5. SMSserver

addNewServer() - adds the server to the system
setupNewSMSserver() - setup the smsserver to allow sending of sms
sendSMS() - sends SMS to the manager/ staff

6. EmailServer

addNewServer() - adds the server to the system
setupNewEmailserver() - setup the emailserver to allow sending of email
sendEmail() - sends email to the manager/staff

Step 4: State Assumptions for the Entity class Diagram

• Manager and Staff do not have access to sites, hence no get/set method. (Sites settled by IT-Admin)

https://app.diagrams.net/#G12UAuTgTEkSQRJ0jT9yAXVKVyjGnD_Rct

https://app.diagrams.net/#G1DlkdR6UiSj3q28Im_DuHLRyYmcJyS-8D

20 September: To supplement the need finding for a client's security company, we have conducted research into what is the commonly used structure to divide working shift hours among staff.
23 September: Completed Research