# Process - Formative Assessment

## Change Management

| Small, frequent commits to the project SCM by all members of the team. |
| ------------------------------------------------------------ |
| Within our group, we split and allocated tasks to different sub-teams. Working closely in team of 2, usually one person will conformed to commits of each feature and push codes on behalf of the other member. By doing so, it allows the each member to understand the codes better when doing together and not be pressured of the new code changes. As for the frequency of the commits, we discussed as a group and we decided to push functional code of each feature instead of small commits to reduce the number of times we perform pull request from the repository. Therefore, the number of commits shown in the diagram may not be reflective of the collective effort done by each member in our team. |
| 
|
| 
|

| 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. |
| ------------------------------------------------------------ |
| Commits made by all of our team members were specific and described the changes that were made to the project. However, although not all the commits made were targeted in reference to an issue as they might be minor issues, most of the commits were targeted with reference to an existing issue in the issue management system. |
| 
|

| Only configuration items are stored in the SCM. |
| ----------------------------------------------- |
| The SCM system contains relevant configuration items and they are the software application code files and its key documents such as product and process report. This allows the team to practice handling changes systematically so that the system maintains its integrity over time by defect tracking and traceability. |
| 
|

| The team has an agreed strategy for managing concurrent development, such as feature branching. |
| ------------------------------------------------------------ |
| Our team used feature branching for the testing and development of different features such as the APIs before committing them into the main branch. This allowed us to distribute the development of features among ourselves and allowed us to develop different features concurrently without the need for constant pull requests from the repository. |
| 
|

## 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. |
| ------------------------------------------------------------ |
| Team had utilised the github’s “Issues” tab to create tasks and milestones to be completed at each iteration. Each issue created is assigned to individual members to distribute overall workload. Issues assigned are tagged with a deadline for completion, its priority level in the process flow, the description and problems encountered when working on the particular issue. In addition, milestones are set after each scrum meeting with the team to set goals and aims for the next iteration. After each iteration, new milestones will be created along the way as the software process progresses.
| 
|

| Tickets frequently updated during the course of the iteration as tasks are completed. New tickets are created as needed throughout the iteration. |
| ------------------------------------------------------------ |
| Frequent updates have been commented for each issue that was worked on to update the team on the progress. On some occasion problems may be encountered while working on some issues, and these problems will be craft as new issues to be completed and discussed in the next scrum meeting |
| 
|

| Realistic estimates of the effort required for the latest iteration were made, such that all objectives were achieved; or the team actively managed the project plan and identify low priority tasks to be removed from the iteration. |
| ------------------------------------------------------------ |
| The team utilised a decision log excel document that captures important decisions made along with the criteria, reason for decisions, questions and status of each decision. The goal of this document is to provide a fast overview of descion records, how to create them, and where to look for more information. |
| 
|

| 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. |
| ------------------------------------------------------------ |
| The Team had created pertinent pages on Github Wiki that have information containing individual members details, our retrospective gatherings, system architecture, presentation details that we had done for each customer days, Gantt Chart that depict our team progress and also meeting minutes after each customer day meeting.
| 
|

* [Design Documentation](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Design-documentation)
* [Project Documentation](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Project-Documentation)
* [Final Documentation](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Final-Documentation)
* [Team Organisation and Milestone](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Team-Organisation-and-Milestone)

## Quality Assurance

| Every commit to master (at least) is tested in a continuous integration environment by executing an automated regression test suite. |
| ------------------------------------------------------------ |
| Members in our team code different functionalities of the application. Our team leader will then proceed to review the code, before merging the branch that we worked on into master.
| 

| The team immediately fixed any broken builds report by the CI environment and no new features are added until this is done. |
| ------------------------------------------------------------ |
| All team members will be notified of any build failure and will proceed to fix the build before the next incremental build proceeds in the testing phase. This is to ensure that the subsequent functional process works fine and not be affected by any failed build committed to the main repository. The task of fixing the failed build will be assigned to the team member committing the build. The team member will notify other members of the team once the build is fixed and the previous failed build passes the test in the CI, such that subsequent commits can be made by the rest of the team members. |
| 
|

| The team performs code reviews, e.g. during a merge request. |
| ------------------------------------------------------------ |
| Members in our team code different functionalities of the application. Our team leader will then proceed to review the code, before merging the branch that we worked on into master.
| 

|

| The software test suite is *effective*. The build/test cycle executes quickly (less than 10 minutes). |
| ------------------------------------------------------------ |
| All the test cases execute and run effectively with an average execution time of less than a min. The longest execute test cycle executed for 1m 4sec and the fastest test cycle recorded 48sec |
| 
|

## Process Improvement

| The team elicited and documented software process issues during the latest retrospective. All team members contribute to the retrospective. |
| ------------------------------------------------------------ |
| During our retrospective meetings, we used guiding questions that helped us to classify elements of our software process. We listed down all the issues that should be improved after every sprint during the retrospective. |
| 
|
* [Retropective](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Retrospectives)

| Software process problems been thoroughly analysed by the team, e.g. by using a 5 whys or other root cause analysis technique. |
| ------------------------------------------------------------ |
| Upon encountering software process problems, our group adopted the 5 whys methodology to discuss the issue at hand. In doing so, we were able to find the root cause of the issue and we were able to tackle the problem at its heart instead of solving problems that did not resolve the issue at all. |
| 
|
* [Retropective](https://github.com/UGS-CS/CSC2002-TP-P04-REPO/wiki/Retrospectives)

| The team identified process improvement actions, documented them and assigned to a team member for monitoring/completion. |
| ------------------------------------------------------------ |
| Process improvement actions are identified through the retrospective documentation every after scheduled customer day and the issues are assigned to the allocated member who is tasked to take up the tasks. |
| 

|

| Results from previous software process improvement actions been evaluated and acted upon |
| ------------------------------------------------------------ |
| Our group identified the actions undertaken from the previous software process development sprint are effective and should be adopted for future project sprints. |
|  |