[M3] Project Management

Resources that are required for this project are a database and a web application tool. Based on the UCP, which is 111, the estimated effort of the project is between 1665 to 3330 developer-hours. Through the software estimation and the project management, it shows the estimated UUCW, TCF and EF required for the project. The duration estimated to complete each task is about 53 to 54 days. However, there are overruns that are due to occur. These overruns are further explained below.

The current status is that the user interface requirements such as the company colors, type of font used, and the type of design that is close to what the client wants. Based on the information gathered during the client meeting, functional and non-functional requirements, the examples of the user interface are created. This is to show the client what the web application will look like when a user logs into the system, the manager landing page as well as the job allocation for both daily and weekly.

Using the Waterfall model, our team is in the ‘Implementation’, ‘Validation and Verification’ and ‘Deployment’ phase. In Milestone 2, our team was in the 'System Analysis and Design' phase. In the 'Requirements Specification' phase, our team had the requirements through the initial requirements in the project overview, client meeting as well as the client email that was sent. These requirements were then analyzed and documented in Milestone 1, specifically under Section 3 'Specific Requirements'. In the current phase, our team further analyzes those requirements and comes up with the system design to be created for the web application. Our team used the n-Tier architecture for the software design and factory pattern for the detailed design. This aids in developing the overall system architecture and establishes the hardware, software and system requirements. Being in the last few phases of the Waterfall model, the prototypes and the wireframes are up. This wireframe is then passed onto the client to be able to use it to run their workload management system.

Work allocations in the project are being assigned individually. Based on what is done in Milestone 1 and 2, the workload is then distributed according to what each member is efficient with. These work allocations are more detailed in the project board on GitHub.

One of the overruns that occurred is the user interface as the user interface needed some confirmation from the client. Based on the client’s response, the updated user interface can then be created for the report. Based on the gantt chart Figure 11, even though the dates and duration were specifically indicated, there are still overruns by at least 72 hours. (here can talk about how many hours incurred by the overrun from the gantt chart)

Changes to the use case model as well as description are made. These changes are made based on the client’s response to the questions that were asked in the client email that is being sent. One of the changes is when a staff or manager resigns from the company, the account will be deactivated instead of deleted. Another change is the reallocation of jobs. When a staff rejects a job with a valid reason, the manager will then reassign the job. The last change is the submission of a late request. When the staff misses the submission period, he/she can submit a late request to the manager, if no late request was submitted after missing the submission period the manager will assume the staff is available to take on any job. Another possible scenario is if the staff did not state his/her availability before submitting, the system will prompt the staff to indicate their availability before submitting. In the use case descriptions, changes were made since there was not a need to mention the user interface components as well as database. There is also a need to provide alternative scenarios if the precondition fails.

For the wireframes, the login pages are for the administrator, managers and staff. The input fields are employee id and password. There is validation for the input fields, such that only when the user keys valid employee id and password then he/she can log in. When the user keys an invalid employee id and/or password, there will be a prompt that he/she has keyed in an invalid employee id and/or password.

The landing pages for the admin, managers and staff are different. The administrator’s landing page can see the same things as the manager but the administrator can see the different accounts that have been created in the company. The manager’s landing page can see the top three lowest workloads for the staff, as well as the staff workload for the week and flag out staff with working hours over 40 hours. The staff landing page allows the staff to view his/her own weekly job assignments and the overall workload for the month.

The manager and staff are able to view their own account by clicking on their own icon to see the details. To edit their own account, they can click on the edit profile button to edit the various fields that are in the edit account page. These fields include the name, email, position, employee id and password. Saving the profile will result in a prompt popping up to state that the account has been edited. To cancel, there will be no changes made.

The staff can submit their availability for the manager to view their availability. Once the manager has viewed their availability, he/she can plan the staff jobs to be assigned to them. The staff can then view their workload after the manager has assigned jobs to them. After the staff has viewed their staff workload, he/she can reject their assigned job. The manager will look through the rejected job assigned and update the schedule.

The last part of the wireframe will be the log out. The administrator, manager and staff will be able to log out of their account whenever possible. He/She will need to click onto the log out button and will be redirected to the login page.

SIT-P5-7 / ICT2201_P5-7

[M3] Project Management #63