7. Software Development Strategy

Release Strategy and Sprints

Development efforts have been split across three major sprints. At the conclusion of each sprint, a release of Signapse has been created. The first sprint has focused on building a bare-bones video processing pipeline, training neural network models for recognition of hand signs and providing an interface to the user via the command line. The second sprint has re-architected the system to make use of the callback design pattern, integrated unit testing with Google's test framework and provided a GUI for user interaction. In the final sprint, the software has been finished to a production standard including refactoring, documentation and remaining unit tests; the product has also been marketed on social media channels.

Take a look at the full set of releases and their additions on our release page.

For a given release, the dev branch is merged to main and a release is constructed after integration tests are shown to have passed. Software on the main branch is always ensured to be passing tests and is always a copy of the latest Signapse release. Commits to main are permitted, but only to update non-code related assets such as README.md or images/ content.

Branching

GitHub branches have been used to allow parallel work on a range of features in tandem. The dev branch constitutes the latest development version of Signpase. Feature branches are always made from dev and usually constitute one or two features. When work on a branch is completed, the branch owner may merge to dev locally and push or a pull request can be carried out and approved by another team member, both these approaches have been used, but pull requests are preferred.

Integration Machines

A key challenge is ensuring feature additions do not break the existing software. To aid with this, GitHub actions have been configured for continuously evaluating the system throughout development. Upon each push, a test is run which first checks the software builds from scratch and then executes the suite of unit tests written. If a merge to dev includes a breaking change, the team is notified via email and effort is expended to fix problems quickly.

A separate integration machine builds and hosts documentation for our code-base. This ensures that the written docs are syntactically valid and are always up to date with each push.

Issues

GitHub issues have been used to track deliverables and divide work among the team. When issues are addressed, their numbers have been included in commit messages where possible. Milestones have been used to assign issue work to the three project sprints, this gives a clear indicator of how much work is required for the next sprint and helps effectively organise efforts to meet the nearest target.

To see the full list of project issues, take a look at our issues page, likewise with our milestones page.