Sportlyzer Game Plan Tree Peer Review

Abstract

This document is a review of the Sportlyzer Game Plan Tree project conducted by team Lasalara. It consists of three main parts – code review, installation test/user experience test and acceptance test – and a summary.

Unfortunately, the client of the reviewed team did not allow sharing of the source code and therefore this document contains observations made during the course of a 2-hour meeting and a subsequent small interview. In addition to this no access to the server source code or iOS source code was granted, therefore this document is based only on the Android version of the application.

Code Review

After analysing the source code, these are the conclusions we reached:

1. Some variables and imports are never used, some methods are not completed.

2. Null is passed as the view root in the main activity file. The following warning is present: “Avoid passing null as the view root.”

3. In some classes static fields are not accessed in a static way. The following warning is present: “Static field should be accessed in a static way.”

4. Not in accordance with Android design guidelines buttons on the upper edge of the screen have borders. The following warning is present in at least some screen size layouts: “Buttons in button bars should be borderless.”

5. Commenting of the project is at times inconsistent and contains incomprehensible words (e.g. “konus”). This is understandable, since there are four different developers from whom none are native English speakers.

6. Rather large chunks of code can on some occasion be found rendering the source code not easily readable.

However, taking into account that the project is not supposed to be finished yet, the situation is understandable and the team still has a couple of weeks to make the necessary adjustments.

Installation Test/User Experience Test

Since the source code was not shared with us and we ran the application from a developer’s laptop, we did not face any problems. Therefore this part of the document will focus on user experience testing. A list of problems we noticed follows:

1. The application crashed quite frequently. This was alarming since there did not seem to be a recurring pattern causing the crashes (except for one bug explained in the next point).

2. Drawing an arrowed line very quickly crashes the program. The lines without arrows at the end work well, the problem seems to arise when trying to draw the arrow.

3. Arrows in the end of lines are sometimes in the wrong direction, when making a sudden turn near the end.

4. Objects (balls/cones/players) and lines cannot be manipulated. Once drawn on the screen, they cannot be moved, deleted or changed.

5. The football pitch looks wonderful, whereas the basketball and hockey fields are low resolution.

6. On the album screen, some game plans have no preview and some game plans lost their preview for some reason during the course of using the application.

7. Player icons are quite large, thus complicating the making of very detailed game plans.

8. When naming a game plan, the user must write the new name and then press “save”. This “save” button might make the user feel it is for saving the game plan, not the name itself. Therefore the button should be renamed to something like “set name” or removed altogether.

9. The images of the four buttons letting you choose the type of line you want to draw should perhaps be changed. At the moment they all portray a line coming from the upper left to the bottom right, a downward line often associated with something negative. Instead, a rising line from the bottom left to the top right could motivate and create positive emotions in the user.

Acceptance Test

Due to the client not allowing full access to the source code we were unable to test server requirements. In addition to this, because of the slowness of the Android Virtual Device, non-functional requirements concerning time also went untested.

From what we were able to test, the following problems arose:

1. There is a name discrepancy where functional requirement FE12 is “User must be able to add soccer ball, basketball or hockey puck to the field” on the Detailed requirements page and “User must be able to redo recent undos” on the Functional requirements page.

2. Functional requirements FE3 and FE5 are not implemented – there is no option to delete objects or lines on the field

3. Functional requirements FE6 and FE12 (on the Functional requirements page) are not implemented – there is no option to undo or redo recent changes.

4. Functional requirement FE11 is not implemented – there is no option to choose between soccer ball, basketball or hockey puck. Also, the objects sometimes seemed to depend on the chosen field and sometimes not.

5. Functional requirement GE6 is not implemented – there is no option to search for game plans in album by name, tags or creation date.

6. Functional requirement GE8 is not implemented – as of yet there is no option to log in to the application.

7. Functional requirements UAC1, UAC2, UAC3 and UAC4 are not implemented.

Summary

Taking everything into consideration, the progress made by team Sportlyzer Game Plan Tree has been impressive, even though some reliability issues occasionally appear.

A lot of problems covered in this document should be rather easily solved. Also, many of the requirements listed on the project wiki pages are not supposed to be implemented before the last iteration.

However I would recommend to the team to profoundly discuss the size of player icons, changing the way naming the game plan works and the appearance of the line type buttons.