# Process

## Change Management

| Small, frequent commits to the project SCM by all members of the team. |
| ------------------------------------------------------------ |
| Based on the graph[1], the team has been making frequent small commits throughout the whole project. Sometimes, there were large commits where the team was rushing out to develop to fulfil the major function requested by the client. The project was then integrated with other modules. We pull changes made from the integrated version into our branch to ensure that our codes are updated with other modules [2].|
|[1]
|[2]

| Commits have informative log messages, explaining the rationale for the change in more detail, with a reference to the relevant ticket in the issue management system. |
| ------------------------------------------------------------ |
|During the software development phase, members used Github version control to commit their latest version of code with informative and descriptive log messages on their progress, changes made, progress and bugs found or fixed. This enabled our team to communicate effectively and better assist one another when required[1].|
| [1]|

| Only configuration items are stored in the SCM. |
| --- |
|The team have included some configuration items into GitHub version control such as configuration file for the GitHub SCM in handling files. Some of the files are the following:|
> * **.gitignore**
This configuration file ignores some files and directories from being checked into the GitHub repository. This usually includes files used by the IDE and project management tools to link system resources required to compile, build outputs and dependency resources. These files are not checked into the repository as they are system dependent and can cause conflict with other team members.
> * **appsettings.json**
This configuration file sets up all the options and secrets for the application. This includes the connection string for the database, secret for signing tokens to be used by clients and SMTP account credentials for emails. Having a configuration file allows the user to modify the actions without having to change the source code.
> * **.editorconfig**
This configuration file sets up the coding convention used by the team, aligning team members' code quality. This allows the code to be maintained easily, as there would only be a single style of coding convention.

---

| The team has an agreed strategy for managing concurrent development, such as feature branching. |
| ------------------------------------------------------------ |
| The team has come to an agreement to conduct our development on the booking system repository. Even though we are working on the same branch, it did not affect each individuals development. Each team member will pull the latest source code before pushing their changes. Any conflicts will be check on before hand to ensure that we did not affect one anothers work. [1]. |
| [1]

|

| Other (optional) |
| ------------------------------ |
| [Change Request Form](https://drive.google.com/file/d/1uR3uqdOlhq-sWiQI1hhgQruVN98ma1r6/view?usp=sharing) |
| 
|

## Project Planning

| Details of tickets (ownership, milestones, issue type, priority etc.) are complete in the issue management system. Milestones exist for each iteration of the project with associated tickets. 100 words max|
|---|
|The booking system teams has came together and agreed to use Trello as the issue management platform[1]. We have designated multiple list such as Backlog, Design, To Do, Code Review, Testing and Done. This lists helps us to arrange the cards (issues) and allows us to assign members to the cards. We can also set a due date to the indivdual cards to help us ensure we are making progress in the time frame. Milestones are declared in the work breakdown structure with Gantt Chart which was done during phase 2 after we had a clearer idea of the deliverables[2].|
|[1]|
||

| Tickets frequently updated during the course of the iteration as tasks are completed. New tickets are created as needed throughout the iteration.- 100 words max |
|---|
|Cards were created as needed for every sprint and updated as the task progresses. Deadline are also set when the cards are created as well as being assigned to the member tasked with completing it[1]. This Cards can be viewed as issues assigned to each individuals. It revolves around how we task each individual in the team and how we keep track of each others work.|
|[1]|

| Realistic estimates of the effort required for the latest iteration were made, such that all objectives were achieved; or the team actively manage the project plan and identify low priority tasks to be removed from the iteration. |
| ------------------------------------------------------------ |
| Planning of the project timeline was done on Microsoft Project after most of the scope has been finalised with Cloud Plus. During which we had defined the timeline and milestones. We had also assigned the tasks accordingly based on available resources. Along the way changes were made to the tasks based on MoSCoW which is an acronym for must-haves, should-haves, could-haves, and would be nice to have. This helped us identify low priority tasks that can be removed from the iteration. |
|[2]|

| The project has a wiki page containing key details such as a summary of the project, the locations of issue trackers and SCM systems, and team member contact details and responsibilities and the change management strategy. 100 words max|
|---|
|Refer to the readMe.md file located in the github wiki - [CLICK HERE](https://github.com/UGS-CS/CSC2002-TP-P08-REPO/blob/master/README.md).|

## Quality Assurance

| Every commit to master (at least) is tested in a continuous integration environment by executing an automated regression test suite. 100 words max|
|---|
|No continuous integration environment was used as the team could not find a suitable automated regression test suite. |

| The team immediately fixed any broken builds report by the CI environment and no new features are added until this is done. 100 words max|
|---|
|There was no CI enviroment used in this project. However, during individual function testing, bugs were immediately rectified before combining the function with the other functions.|

| The team performs code reviews, e.g. during a merge request. |
|---|
|Trello board code review before moving to Done card|
| |

| The software test suite is *effective*. The build/test cycle executes quickly (less than 10 minutes).Comment here - 100 words max|
|---|
|No test suite used. Only manual testing, which listed down all functions and button behaviour. The testing strictly followed the test cases. |
|[Test Case](https://drive.google.com/file/d/1rapyezT0oE2my3k_v2APFVr01OJglE3O/view?usp=sharing)|

## Process Improvement

| The team elicited and documented software process issues during the latest retrospective. All team members contribute to the retrospective. 100 words max|
|---|
|The 2 teams involved in the booking system have done their retrospective sprints together on a trello board during which we will list down our thoughts on the current process based on 3 lists, What Worked Well, What Could Be Done Better, What Will We Do In The Next Sprint and Other Comments. From there we would discuss on how we should proceed moving forward. |
|[2][TP-P08 Meeting minutes](https://github.com/UGS-CS/CSC2002-TP-P08-REPO/wiki)|
||
||

| Software process problems been thoroughly analysed by the team |
|---|
| To tackle the problems analysed by the team, we have utilise root cause analysis as one of our main techniques. Steps were followed in terms of defining the problem, collecting data relating to the problem, identifying cause issues, identifying the solutions to the problem and monitoring and sustaining to ensure a long term effect of the solution.|

|The team identified process improvement actions, documented them and assigned to a team member for monitoring/completion. 100 words max|
|---|
| After analysing the root causes and solutions, members were tasked in trello based on the completion of the task. Monitoring of the process was also tasked to the given member.

| Results from previous software process improvement actions been evaluated and acted upon 100 words max|
|---|
|An example of a process which we improved on was the communication between the 2 teams involved in the booking system. As the inadequate communication was hindering the process previously since both teams did not know what to expect from each other. Following which integration became a smoother and fast process.|

| Other (optional) |
| ------------------------------ |
| [Comment here - 100 words max] |
|  |