Second Week Testing
This week focused on finishing the last couple of features and testing. Development is coming to an end thus some of the extra features have been moved to out of scope. Both the OneDrive login and import panel have been reworked, allowing multiple OneDrive accounts to be used.
The Plan Will Work?
Before starting development the largest concern was the relatively short amount of development time, 6 weeks, for such a large project. Having only 6 weeks forced us into an “only core features” corner, removing any unessential features, leaving us with the purest form of the system. Using each feature was planned out within the 6 weeks following a simple but effective template.
Each week of development time will correspond to one sprint, each sprint is a Trello list. Each sprint list will have a corresponding Pending and Done list, indicating which features are currently in development or completed respectively. Additionally, the Out of Scope list holds all the features which have chosen to be unessential, in total the Trello board contains 24 lists. Using , a Trello extension, I estimated the number of hours each feature would take, once a feature was completed I would document the actual number of hours the feature took. In the end, the Trello board will provide a full diary of development.
According to the plan the development time would take an estimated 160 hours or 4 and 1/2 weeks leaving approximately 2 weeks of extra development time. Breaking down the 160 hours, I predicted the largest task, , would take a total of 79 hours on the other hand Authentication and Search Page UI, the smallest tasks would take a total of 17 hours. The two weeks of extra development time would be planned out closer to the time.and
I love it when a plan comes together, well this plan didn’t, not at all. A combination of the dreaded unknown unknowns and the popping of extra features pushed back development time by a number of weeks, sprint 8 was the predicted finishing time the actual finishing time was roughly, sprint 10. The first two weeks of development, sprint 4 and 5, focused on the backend implementing each endpoint and database queries. In total the sprint 4 and 5 took me an actual of 75 hours, 17 hours quicker than the predicted number of hours. Development time for the backend was quick due to earlier preparation, the weeks leading up to development time I had thoroughly investigated each API and the authentication flow minimizing the chance of an unknown, only minimizing, the inevitable did happen. On sprint 5 an how I fixed the issue.error occurred tagging 3 extra hours of development time, you can read
I was hopeful for future sprints, continuing with the same rate of progress I would finish the whole project even earlier, I would soon learn the harsh lessons of software development. Akin to earlier sprints, the start of sprint 6 development was relatively smooth completely finishing the import panel, implementing the search on the other hand was a whole different fight. The first major unknown occured, a , followed by the back button breaking totalling in 13 hours fixing bugs rather than development. In total sprint 6 took 41 hours instead of the predicted 21. A similar story persisted throughout the sprints 7 to 10 on average development time took 15 hours longer than expected. My hard-fought software development tale is not a unique one it is the nature of the beast, development is incredibly hard to predict, the most common reason software fails, its important to make the plan flexible reducing the chances of a break.
In addition to unknown bugs, minor changes and features were added between sprints 9 and 10. When a new feature is added to the plan I first labeled it as an extra feature, secondly using scrum I predicted how long development time will take. If an extra feature could not be completed it was moved to the Out of Scope list clearly showing to the developers and client which features are not within the plan. Overall a total of 12 features were added ranging from UI changes, dynamic axis labels, to new API endpoints, file storage logout endpoint.
Release and Issues
Every day, with the exception of Monday, a new version of the system has been released allowing both developers and clients to see the progress being made each day. Last week Version 0.1 of the system was released by the end of this week version 0.1.5 will be released.
With each new release comes a corresponding release note, detailing the changes made and bug fixes. For example version 0.1.1 release note,, outlines one major change, annotation operations are persistent, and three bug fixes. Each bug fix links to a closed GitHub issue which provides more issue detail and the fix.
Mentioned last week with the release of Version 0.1, 22 issues were found this week an additional 15 were added, soon the Github issues list will be too unruly to navigate. To combat the unruly nature of the issues list I first ensured each issue followed a similar structure. Each issue contains three parts:
The current behavior, detailing the issues behavior,
The expected behavior, how the system should act
How to reproduce the current behavior, the steps needed to reproduce the issue.
Having a consistent structure ensures each issue contains all the necessary information, aiding the developer to efficiently fix an issue.
Furthermore, a number of Github Issues labels were used to quickly describe the issue as well as group similar issue types together. When a new issue is added it is first tagged with the appropriate labels. If a new label is needed, a new label is added either by the client or the developer. Similar to the issues list if too many labels are created using them effectively can easily become unruly.
For the Github Issues list, the labels fall into three main categories:
Type of Issue
Location of Issue
The type of Issue falls into three subcategories, bug coloured red and the rest shades of blue:
, the features current behaviour is not what is expected
, a whole new feature to the Single Page Web Application (SPA)
, a minor change to the SPA UI
The location of Issue falls into 3 three subcategories coloured shades of green:
, issue occurs on search page of the SPA
, issue occurs on graph view of the SPA
, issue occurs on annotation panel on the view page
, issue occurs everywhere
A single issue is always tagged with a main version, type of issue and location but may be tagged with a number of subcategory labels. One example is the ““, this issue is tagged with a version number and location and two types Enhancement and UI-Change.
All the labels can be viewed, take note of the number of issues.
In addition to adding issues, many issues were closed so far 10 issues have been closed, take a look
This week the Issue list still seems to be growing everyday but all features have been completed. System releases will still continue next week as well as testing. Furthermore, as next week is my last week all documentation and handover will be complete.