During the development of Pathways the team followed two distinct project management methodologies. Initially we made use of traditional waterfall development methodology, completing tasks in a set order to a set schedule. Early in the development process we identified the weaknesses of waterfall development methodology and from previous experience we pivoted the management approach to follow AGILE, and particularly SCRUM, methodology.

SCRUM methodology allowed every member of the team to work intensely for a set period toward a set objective. Almost all product development was completed during one of several intensive SCRUM sprint sessions of 3-6 full time days with all team members present. At the start of the sprint period a product backlog was agreed upon and development priorities were set. We would then work together towards these goals in fluid roles, supporting one another as and when skillsets required assistance. At the end of the sprint period work completed would be evaluated and tested, with goals set for the next sprint.

SCRUM methodology suited the project well, and we found that co-locating the team and working intensely for a period of several days was very effective. Sprints allowed us to make substantial progress with development, to work fluidly and to handle requirements churn, which we experienced with implementing team management and photo uploads, two significant technical hurdles.

In addition to SCRUM sprint sessions the development team would have a daily ‘stand-up’ meeting remotely via Slack, to quickly touch base on progress and outstanding issues, and to ensure no member of the team was awaiting input from anyone else. We would also meet regularly to discuss progress during more substantial meetings to discuss progress and present individual work completed.

A number of professional collaboration tools were utilized during the Pathways project to allow the team to work cohesively when apart.

Slack

Slack is an extremely powerful communications platform, enabling extremely efficient inter-team communication. We configured Slack to include integrations with Github and CircleCI. Every commit or issue raised would trigger a Slack notification, as would every subsequently deployment. This enabled the team to work very efficiently.

Github

Github was used to host the team git repository. Github is a useful tool, and it powerful when combined with Slack for team-wide notifications. In addition to version control, we used Github’s issue tracker system to handle internal bug tracking, often in combination with the client-facing bug tracker provided by AxoSoft.

Below is the commit history for the COMP2014 period.

Axosoft

Axosoft ticket tracker is an industry standard agile project management tool. We used this tool as a client facing platform to handle support tickets, feature requests and bug reports. We utilized two ticket tracking systems, Github for internal-only and Axosoft for client-facing tickets. This enabled for very professional management of support requests and bug reports; the client is separated from unnecessary technical details but can still report bugs and check updates, whilst the development team can raise internal issues and track specific details a client would not want exposure to. The status of this client facing ticket tracker was given in the bi-weekly reports, to provide an insight into of the current work stack of the development team and known issues.

Dropbox

Dropbox shared folders were used to manage shared resources such as presentations, reports and graphics for the project.

An overview of the Pathways development tool chain can be seen in the below diagram.

Microsoft Azure

Pathways is hosted on Microsoft Azure. Microsoft Azure was selected for a number of reasons, including its recent certification as NHS security compliant. We are able to monitor the performance of the application through Azure, and should the application be rolled out beyond the Guy’s and St. Thomas’ NHS trust the Azure instance would allow us to scale easily and comparatively cheaply. An additional advantage of Azure is its pay for what you use pricing structure, allowing for extremely cheap beta testing and cost effective scaling.

Ruby on Rails

Ruby on Rails was selected for this project after extensive consideration of the options available. Django, Flask and several PHP frameworks were considered as alternatives, however Ruby on Rails was selected for a number of factors. Firstly, Ruby on Rails allows for extremely rapid prototyping, with built in functionality for easy database migrations. This enabled us to iterate quickly through designs and respond quickly to the requirements churn expected on a project such as this. Ruby on Rails also has a large array of community-developed and support tools, which are referred to as gems. We were able to use these gems across the project to quickly introduce functionality that would otherwise have been significantly more labour intensive.

Capistrano

Capistrano was used to entirely automate deployment, for every repository change into the live Azure instance. This was an extremely valuable resource for the team; we were able to push code live into the production environment extremely rapidly from our respective development environments. We faced initial technical difficulties configuring Capistrano, however the time saved avoiding manual deployments more than compensated for this preliminary effort. Capistrano has been configured to deploy via SSH for extra security.

CircleCI Continuous Integration

CircleCI was employed in the deployment chain to test every commit against a predefined suite of tests. When these tests failed the CircleCI integration in Slack would notify the development team, and the build would not be pushed to Capistrano for deployment. When the continuous integration suite of tests was successful CircleCI would notify the team of the successful build and it would be deployed into production in minutes. Our average deploy time is 124 seconds from running a push into the Github repository.

Continuous Integration was utilized during the development of pathways. This is an industry standard development practice and enabled rapid identification and resolution of issues, which could have otherwise remained unnoticed for significantly longer. This approach coupled extremely well with our agile scrum methodology, and enabled us to operate very efficiently during sprint sessions.

Rspec

Rspec was used to automatically test Pathways throughout development and as a step within continuous deployment. This is covered in more detail in the test section.

Postgres

Postgres was used to handle all the database requirements of the project. Postgres is a widely supported alternative to MySQL with high benchmarks and more supported data formats, such as JSON. More information on the use of Postgres can be found in the Implementation section of this website

Deployment Diagram

The below diagram shows the deployment pattern described above.

Faker

Large quantities of information was required to test Pathways before production. This information was crucial to test data flows and user experience in the application, without the need to manually create hundreds of patients, doctors, states, modules and superusers.

Paperclip

Paperclip is a gem used to handle the complex problem of custom image uploading within Pathways. This resulted in members of the medical team being able to upload custom images to support information in the application.

Slim HTML

HTML slim is a templating language that compiles into HTML. As HTML is a much more verbose language, Slim was used to enable more efficient front end development.

Rubocop

Rubocop is a code static analysis tool. It was used to enforce code quality throughout Pathways. Rubocop uses community agreed coding style guidelines to suggest changes to the codebase. As part of continuous integration, code quality was analysed on each deployment and if it did not pass community standards, the build would be rejected and not deployed.

RailRoady

RailRoady was used to generate system diagrams from the finished database to demonstrate how the application functions and for comparison to the initial system design.

Bootstrap

Bootstrap is a powerful front-end development library, containing resources to significantly increase the rate at which design is possible. Use of Bootstrap enabled us to implement responsive design, and to ensure all buttons, forms and dialog boxes were consistent throughout the application.

JQuery

JQuery was used to manage the date picker functionality when updating and creating treatment states.

PG

PG is a gem which provides an abstraction over interacting with the Postgres database from within Ruby. As working with raw SQL can be difficult and potentially introduce security issues, we used the PG gem to alleviate these concerns.

QuillJS

Quill was the text editor framework we used to allow Pathways to support information given with rich content. So that this framework would meet our requirements, we needed to fork this library and make custom changes to its implementation. These changes we made to allow for the use of images within information modules given to patients.