... | ... | @@ -50,17 +50,23 @@ |
|
|
* Front End
|
|
|
* Responsible for All Leagues, League, Team and Member pages, pop-up pages, and the design theme for the application.
|
|
|
* Will ensure the theme is consistent throughout the application and each page is layed out cleanly.
|
|
|
* Lee:
|
|
|
* Lee
|
|
|
* Back End
|
|
|
* Responsible for java classes, interfaces and assisting in database operations.
|
|
|
* Will ensure back end code is efficient and of sufficient quality.
|
|
|
* Jay: Responsible for the complete sidebar navigation menu and home page. Will ensure that user navigation is intuitive & smooth, and that the respective GUI components work as expected.
|
|
|
* Shantanu:
|
|
|
|
|
|
|
|
|
## Test Methodology
|
|
|
*
|
|
|
* Regression testing is applied at the unit level to each back-end java class in our model, each back-end java class has a corresponding testing class used for testing the methods and functionality of that particular class. The JUnit framework is used to support this. Unit testing is done by the developer who implemented the class itself, these tests are verified during inspection.
|
|
|
* The app is tested at the system level as new features are added, for example if a new screen is developed, the screen and its interactions with the rest of the system are tested and explored before the new changes are added to the repository. This testing takes the form of trying various inputs and actions with a test version of the application; for example if some database functionality is being tested, a developer might input various values to some interface and ensure that the correct values are written to the database by inspection. This may be done by the developer responsible for these changes, by the developer verifying or inspecting these changes during a merge, or both.
|
|
|
* Bugs can be reported informally in person or via slack to the relevant developer, or a new issue can be created describing the bug with the relevant developer assigned to the issue.
|
|
|
|
|
|
|
|
|
## Inspection Methodology
|
|
|
*
|
|
|
* Code inspection and review occurs before a developer merges one of their branches back into our main development branch. By convention each developer creates a new branch whenever they have changes to make, once these changes are implemented and tested this branch is merged back into our development branch. At the time of this merge a developer asks another developer to look over and approve of their changes, the developer doing this inspection should be aware of the nature of the changes being made. For example asking a developer whose main focus is on the database to inspect change to the front-end user interface of the app is bad practice as the database is unrelated to the UI. The inspecting developer views the changes made, assesses code quality and does testing of their own. The inspecting developer then decides to accept and merge in the changes or deny them if quality is not met.
|
|
|
* No formal documentation or artifacts are produced during this process, an inspector may give informal verbal or written feedback to a developer however. Likewise there are no formal guidelines for code quality or practices, however quality requirements have been discussed as a group, and the judgement of each developer should be sufficient for a project of this size.
|
|
|
|
|
|
|
|
|
## Action Plan
|
... | ... | @@ -70,7 +76,7 @@ |
|
|
* Created a League page which is the same as the All League page but instead shows teams and a pop-up for adding a new team.
|
|
|
* Created a Team page which shows the record for the team, next scheduled game, and a list of the current members.
|
|
|
* Created the two pop-ups mentioned before for adding either a new League or Team.
|
|
|
* Lee:
|
|
|
* Lee: Implemented Storage class that can read and write to database, created singleton pattern class containing information about the current user of the app. Now when a new League is created, this league is written to the database.
|
|
|
* Jay: Added scrollable teams list to the homepage, showing all individual teams that the user is part of. Currently, it shows hard-coded teams (for testing). This will be modified later to get the teams from the firebase database for the user. When a team is clicked, it goes to the individual team info page (which also has hard-coded info, for now). I wrote the scope for this milestone.
|
|
|
* Shantanu:
|
|
|
* Work to be completed next week:
|
... | ... | @@ -78,7 +84,7 @@ |
|
|
* Create a Member page for displaying the information about a user.
|
|
|
* Add a floating action button for adding a new member to the team. This will be visible only to the owner of a team.
|
|
|
* Add a seperated owner field above the member list in the Team page.
|
|
|
* Lee:
|
|
|
* Lee: Refactor League, Team and Member classes to facilitate reading and writing to database; create Info interface and objects to do this.
|
|
|
* Jay: Will update the homepage to show user specific teams from the database (once we figure out how to do that). Will also work on the profile page for individual users.
|
|
|
* Shantanu:
|
|
|
|
... | ... | |