Production Project: Project Evaluation Report by Joe Houghton

2

Date of Submission: 14th April 2016 Version: 1 Course: BA (Hons) Computing Student Id: C3375905

Abstract This report documents findings and observations made while experimenting with multi-page and single-page applications, to develop an online service for sharing patient bed availability across the NHS and with private care providers. It captures the strong collaboration between developer and product owner and the varying methodologies utilized to plan and adapt to change. Design techniques used to aid and share understanding of the system through visual representation are evaluated. A critical product evaluation offers insight to successes of the project as a whole, and how aims and objectives were achieved to a high standard by rigorously testing implementation. Impediments throughout the project are explained, along with actions taken to resolve them. Recommendations for future development are provided by reflecting on developer performance, to determine what is achievable in the next scope of work.

3

Table of Contents 1 Introduction ......................................................................................................5

2 Research & Investigation .................................................................................6

2.1 Experimentation .........................................................................................7 2.1.1 Error Messages & Form Validation ......................................................7

2.1.2 Layout & View Reuse ..........................................................................8 2.1.3 Authentication & Security .....................................................................8 2.1.4 Accessing the Current User .................................................................9 2.1.5 Findings ...............................................................................................9

3 Methodology ....................................................................................................10

3.1.1 Adopting Methodology .........................................................................10 3.1.2 Daily Stand-ups ...................................................................................10 3.1.3 Requirements Gathering ......................................................................10 3.1.4 User Stories .........................................................................................10

3.1.5 Role Modelling .....................................................................................11 3.1.6 Sprint Planning ....................................................................................11 3.1.7 Kanban Boards ....................................................................................12

4 Product Design ................................................................................................13

4.1.1 UML Modelling .....................................................................................13

4.1.2 Usability ...............................................................................................13 4.1.3 Responsive Design ..............................................................................13

5 Product Implementation and Testing................................................................15

5.1.1 Regression Testing ..............................................................................15 5.1.2 Unit Testing with NUnit ........................................................................15

5.1.3 Optimisation .........................................................................................16

6 Product Evaluation ...........................................................................................17

7 Project Evaluation ............................................................................................19

8 Summary ..........................................................................................................21

9 Appendices ......................................................................................................22

9.1 Appendix A .................................................................................................23 9.1.1 Appendix A1: Wireframe Designs ........................................................23

9.1.2 Appendix A2: UML Use Case Diagram ...............................................25 9.1.3 Appendix A3: UML Class Diagram ......................................................26 9.1.4 Appendix A4: Mock-up Designs ...........................................................27 9.1.5 Appendix A5: Mock-up Design Feedback ............................................31 9.1.6 Appendix A6: NUnit Unit Testing .........................................................32

9.1.7 Appendix A7: Server-side Separation ..................................................33 9.1.8 Appendix A8: JsHint and JSCS-Stylish ...............................................34

9.1.9 Appendix A9: DbUp Console Application.............................................35 9.1.10 Appendix A10: Specflow Automated Browser Testing .........................36 9.1.11 Appendix A11: Git Branches ................................................................37 9.1.12 Appendix A12: Git Commits .................................................................38

9.1.13 Appendix A13: P4Merge Merge Tool ...................................................39 9.2 Appendix B .................................................................................................40

9.2.1 Appendix B1: Form Validation .............................................................40

4

9.2.2 Appendix B2: OAuth Bearer Tokens ....................................................41 9.2.3 Appendix B3: Refresh Tokens .............................................................42 9.2.4 Appendix B4: Token Storage ...............................................................43 9.2.5 Appendix B5: Experimentation Results................................................44

9.2.6 Appendix B6: Responsive Design .......................................................49 9.2.7 Appendix B7: Protected Resource .......................................................51 9.2.8 Appendix B8: Authentication ................................................................51 9.2.9 Appendix B9: User Detail .....................................................................52 9.2.10 Appendix B10: Organisation Detail ......................................................52

9.2.11 Appendix B11: Find Beds ....................................................................53 9.2.12 Appendix B12: Search by Care Requirements ....................................54

9.2.13 Appendix B13: Geocoded Locations ...................................................55

9.2.14 Appendix B14: Search Result Selection ..............................................56 9.2.15 Appendix B15: Booking Request Sort .................................................57 9.2.16 Appendix B16: Booking Request Filter ................................................58 9.2.17 Appendix B17: URL Decoding .............................................................59 9.2.18 Appendix B18: IIS Permissions ...........................................................60

9.3 Appendix C.................................................................................................61 9.3.1 Appendix C1: Trello Kanban Boards ...................................................61 9.3.2 Appendix C2: Product Owner Meeting Minutes ...................................63

9.3.3 Appendix C3: End of Sprint Retrospective Reports .............................70

9.3.4 Appendix C4: Risk Assessment ...........................................................85

9.3.5 Appendix C5: Consent Form ...............................................................86 9.3.6 Appendix C6: Communication Schedule .............................................87

9.3.7 Appendix C7: Document History and Version Control .........................89 9.3.8 Appendix C8: Revision Numbering System .........................................91 9.3.9 Appendix C9: Google Keep .................................................................92

9.3.10 Appendix C10: Gantt Chart ..................................................................93 9.3.11 Appendix C11: Harvest Time Tracking ................................................94

9.3.12 Appendix C12: Project Supervisor Meeting Minutes ............................96 9.3.13 Appendix C13: Starfish Exercise Diagrams …………………………...102

9.4 Appendix D…………………………………………………………..………… 103

9.4.1 Appendix D1: Regression Test Script…………………………………..103 9.4.2 Appendix D2: Definition of Done………………………………..….……109 9.4.3 Appendix D3: Story Point Estimation……………………………....…...110

9.4.4 Appendix D4: Requirements List……………………………………...…115 9.4.5 Appendix D5: Skills Audit……………………………………………...…117

9.5 Appendix E………………………………………………………………...……118 9.5.1 Appendix E1: Project Plan……………………………….………….……118

9.6 Appendix F…………………………………………………………….…..……132

9.6.1 Appendix F1: User Journey……………..…………………….…………132 9.6.2 Appendix F2: User Guide……………..……………………….…………136

10 Bibliography…………………………………………………………………………137

5

1 Introduction The NHS currently face the crisis of finding patient bed availability. As a result, patients are left without adequate care and are admitted to facilities miles from their homes, relatives and support systems (Corbyn, 2015). The motivation for the project is to design and implement an online service for sharing patient bed availability across the NHS and with private care providers. The proposed system aims to enhance patient care, by allowing beds to be found closer to patient’s homes. Given the current demand for an application to solve the current bed shortage issues across the UK, the proposed system needs to be proven both for performance and sustainability, but also for the development and maintenance, therefore this report looks at two design architectures and their pros and cons. Strong collaboration and iterative planning with an NHS bed manager was essential to capture knowledge over time, to refine and maintain a clear set of requirements, forming a minimum viable product that is hoped to be demonstrated with neighbouring mental health trusts and private providers. A wide range of literature was covered and through research traditional multi-page and modern single-page application architectural patterns were identified as potential ways to build a scalable application. Theory was put into practice when creating two proof of concept applications, in order to share first-hand knowledge with the product owner before making a consensus based decision of how to structure the production product. This report provides insight to trending web architecture and documents findings and observations made when developing each prototype product. Design techniques used to aid and share understanding of the system through visual representation are evaluated. A critical product evaluation offers insight to successes of the project as a whole, and how aims and objectives were achieved to a high standard by rigorously testing implementation before marking it complete. Impediments throughout the project are explained, along with actions taken to resolve them. The report discusses varying usages of methodologies used to successfully plan and adapt to change over a 7 month duration. Realistic recommendations for future development are provided, along with a summary of end of sprint reports, reflecting on developer performance to determine what is achievable in the next scope of work.

6

2 Research & Investigation The World Wide Web is rapidly evolving and a range of technologies have been created aiming to enhance user experience and aid developers to quickly create powerful web applications (Pop et al., 2015, p.1172). Research into web architecture was required to find the best approach for the project. Applications today are composed of client-side and server-side technologies. HTML and CSS are used in the front-end to present data, and user interaction is achieved with JavaScript. The server-side is responsible for data processing and storage. As dynamic web pages became popular, developers began to combine HTML with server-side technologies resulting in intertwined and unmanageable code (Pop et.al., 2015, p. 1172). Design patterns were introduced to leverage this problem and MVC is a popular choice that separates the presentation layer from the domain model (Cortez, 2014, p. 412). MVC applications are composed of three parts, the model, view and controller. The model is responsible for data processing by establishing a database connection, querying data and enforcing business rules. It passes data to the view without consideration of data presentation. This means multiple views can be created using the same data, remaining independent from one another while listening for model changes. This improves code maintenance and increases usability (Sabir, 2013, p. 7). Pop et al (2015) advise taking the ‘Thin Model’ approach, extracting business logic out into controllers, only keeping data processing in the model that is tied to the real life object being modelled. This approach enhances the reusability of models between applications (Pop et.al., 2015, p. 1174). It is the controller’s job to handle events created by system processes or users interacting with the view. Controller methods process request data and respond by generating a view, passing in data retrieved from the model. Controllers are also responsible for defining the format of the response (Pop et.al., 2015, p. 1175). The view layer is responsible for managing user interface components such as forms, graphics and text. Good practice suggests that a view should not contain business logic and logical blocks of code should be kept to a minimum. This makes views easier to work with and reduces the chances of the build being broken when a designer is amending styling (Pop et.al., 2015, p. 1175). MVC applications are built on a multi-page interface model, were a hard browser refresh is required for each data request (Renien, 2015, p. 29). Through the power of HTML5 and JavaScript, Single Page Applications (SPA’s) have been introduced, based on a single-page interface model. These applications contain a single HTML page, were components can be updated independently using AJAX, without the need for page reload. This improves interactivity, responsiveness and user satisfaction (Renien, 2015, p. 30). SPA’s are beneficial as they offer less bandwidth. By downloading all data on the initial request, it means JavaScript libraries are only loaded once, reducing round tripping. This allows for faster navigation, as the browser has the required mark-up to display the view and additional requests to the server to generate mark-up aren’t necessary. Asynchronous calls are made to the back-end to retrieve data which is often returned in JSON format (Etter, 2012). Client-side JavaScript frameworks such as Angular.js and Backbone.js have been created to structure SPA’s using MVC architecture, offering data binding, templating engines and dependency injection (Renien, 2015, p. 30). These frameworks do not package a server-side

7

solution and unlike traditional MVC frameworks, views are not coupled with domain models which may compromise the models privacy (Cortez, 2014, p. 413). Instead, REST architecture is used to separate the client and server. Data is retrieved from resources in the form of URIs, using a set of predefined HTTP verbs. This allows for separation of responsibilities, maintainability and independent development (Sundvall, 2013, p. 24). When selecting an MVC framework, it must allow developers to interact with stored data easily. Object-relational mapping is advised, a mechanism to store data in a relational database and retrieve data in the form of domain objects. This allows developers to work with data using object-oriented concepts (Pop et.al., 2015, p. 1176). Microsoft Entity framework is identified as a popular choice, allowing developers to perform queries using LINQ to retrieve and manipulate data as strongly typed objects. LINQ saves developer time by automating CRUD operations. Entity Framework maps domain objects to relational objects, separating database design from domain class design, enabling reusability of classes if the database is swapped out in future development (Entity Framework Tutorial, n.d.).

2.1 Experimentation

As part of research, experiments were conducted to gain a broader understanding of technologies discovered in literature review, before a suggestion could be made using first-hand knowledge for the production product. Two proof of concepts were created over separate sprints, each lasting a duration of two weeks. The first prototype product was a multi-page MVC application built with Microsoft .NET MVC framework. The second prototype was a SPA built with Microsoft .NET Web API framework and Backbone.js. For consistency, the same user stories were used for each application and added to the backlog of separate Kanban board’s (Appendix C1). As explained in section 4.1.2, mock-up designs were created prior to implementation. Wireframes (Appendix A1) were created for the prototypes to achieve these designs, to limit the amount of views used and enhance reuse, to test if both architectural patterns were capable of rendering different regions on the same HTML page and to test the flexibility of each frameworks view engine.

2.1.1 Error Messages & Form Validation

MVC JQuery.validate.unobtrusive.js is packaged with .NET MVC framework and the validation provided didn’t provide the desired look and feel of the mock-up designs. To compensate, jQuery was written in error-alert.js to check for errors on form submission and remove the default styling. Additional jQuery was applied to add the desired bootstrap classes to the form field inputs (Appendix B1). Working with conflicting JavaScript was time consuming but it was decided to keep JQuery.validate.unobtrusive.js for the full framework experience. In .NET MVC, form errors on login are added to the ViewData.ModelState object. An MvcHtmlString extension method was written to check if errors exist in the object and format each error into an HTML string which is rendered in the _ErrorContentPartial.cshtml view. Success messages however were not present in the ModelState object and had to be rendered differently. The solution was to pass success messages from controllers to views via a TempData object. Using razor syntax, an if-statement checks to see if the TempData object contains a value to be rendered, each time the view is initialized. From a design perspective, a combination of approaches to check and display alert messages is not practical, as code has to be maintained in several places.

8

SPA A backbone.validation.js plugin was used to validate form data against the model state. In validation.js, Backbone.Validation.callbacks were used to access form fields of invalid attributes and append the desired bootstrap CSS classes to invalid fields. This solution is preferable over the implementation in the MVC prototype as it automatically validates and applies styling to all fields across the application (Appendix B1). The SPA prototype makes use of Backbone Channels, a combination of Backbone events and radio requests (MarionetteJs, 2016). An alert channel is setup in alert.app.js with handlers to listen for events named warning, success and error. The event functions take a message parameter and pass messages to the ErrorController to be rendered in the error region and appended to the error-content div in index.html. Channels allow error message handling to be located in one place and decoupled from controllers and views. Validation messages triggered in Backbone.Validation.callbacks are automatically passed to the alert channel and rendered in the browser meaning that jQuery doesn’t have to be written for each form to listen to changes.

2.1.2 Layout & View Reuse

MVC In the MVC prototype a parent view named _Layout.cshtml was created, containing areas header-content, error-content and main-content. Content was added to these sections using partial views. The login view returned from the account controller was rendered directly into the main-content area of the parent view. However, the organisation and user detail designs included a sidebar, and so a nested template named _LayoutInner.cshtml was created containing sections Sidebar and ManageContent (Appendix A1). Both organisation and user controllers returned views using this template, and _HeaderPartial.cshtml and _SidebarPartial.cshtml views were specified with razor view engine to be rendered into these sections. With partial views, _LayoutInner.cshtml was nested into the main-content area of the parent view to achieve the desired design. SPA Marionette Layout Views were used in the SPA prototype. The regions error-content, header-content and main-content were defined in app.js and Marionette Objects, similar to MVC controllers used these to append regions to the DOM. Although both sites achieved the same design, Marionette in the SPA proved to have more flexibility and promote view reuse. .NET MVC framework follows a convention that controller actions return views with the same name, suggesting that views and controller methods are coupled. Marionette takes a more modular approach as views are isolated from controllers. Views can be called across application and when initialised, passed an object of any set of options, adding flexibility (Williams, 2014). Being able to dynamically add and remove nested regions was considered an important factor, to enhance scalability. Marionette in the SPA offered show and hide functions to add and remove sections from the DOM without page refresh, reducing a lot of boilerplate jQuery. This functionality did not come with the .NET MVC framework and although achievable, extra code would have to be written.

2.1.3 Authentication & Security

MVC ASP.NET MVC framework is packaged with ASP.NET identity membership system, which saved development time. Although it contained boiler plate code for social login providers which were not needed and had to be removed.

9

SPA Backbone.js didn’t offer a server-side solution and from research it was identified that the best way to implement authentication between front-end applications and server-side APIs was by using tokens and cookies. This was a steep learning curve as Backbone.js tutorials were scarce. Knowledge had to be obtained and applied from Angular documentation. The backend of the application was created using ASP.NET Web API and Owin Middleware. An authorization service was created to accept user credentials and issue an Oauth bearer token on success (Appendix B2). Passing the token on subsequent requests returns a refresh token to increase the length of the user’s session (Appendix B3), although this will not be used in the production product as a simpler solution is to increase the session timeout. The Backbone.ajax function was overridden to send the initial request with URL encoded user credentials to the token endpoint. On success, the authorization token issued is set in a cookie (Appendix B4). To retrieve data from the API, the token had to be present in the requests Authorization header. Putting the theory into practice was challenging, and several attempts were made by overriding Backbone.sync, Backbone.ajax and ajaxSetup before the solution ajaxPrefilter was found to set the header a cookie existed. Unlike the login request, subsequent request data had to be sent as JSON and so the header had to be set accordingly. Although research pointed to this implementation, this approach turned out to be problematic during in future sprints (See section 6).

2.1.4 Accessing the Current User

MVC Being able to access the current user on the server-side was straight forward in the MVC prototype. No work was required to store user credentials at login for future access. .NET classes had a default reference to the System.Web namespace and so current user credentials could be retrieved from the HttpContext using User.Identity methods. SPA For the SPA prototype, a claims identity was created in the GrantResourceOwnerCredentials method to store the current user’s Username, Id and Role as claims. A CurrentUserProvider class was written to retrieve these claims and an ICurrentUserProvider interface was created and injected into each of the web API controllers at to access claims at runtime. The Role and Id claims were retrieved using the Thread.CurrentPrincipal class. However, the Username was only accessible from Http.Context.Current class and so dependency injection was required to inject an HttpContextWrapper containing this class into the CurrentUserProvider constructor for access.

2.1.5 Findings

Both prototypes were completed within the same timeframe and presented to the product owner, who commented that the user experience of the SPA felt “smoother” because the page did not reload on navigation. The product owner stated that the determining factor for the final implementation was speed, and by analysing network traffic, it was identified that the SPA was the fastest application to fetch data and render views in the browser for each view of the prototype design (Appendix B5). While exploring multi-page and single-page applications in depth, developers identified two recurring problems; repeated CSS code and unsynchronised local and production server database tables. These issues were resolved when developing the production product (See section 5.1.3).

10

3 Methodology 3.1.1 Adopting Methodology

A Gantt chart was created at the beginning of the project in an attempt to map out the software development lifecycle. While this approach was beneficial to mark project milestones, it was not possible to plan work on a weekly basis due to the uncertainty of the system requirements. Methodologies were explored and it was decided to move from a traditional methodology to a modern agile methodology, with the intention of iterative planning to capture knowledge over time rather than dictating specific phase’s upfront (Papadopoulos, 2015, p. 456). The DSDM agile framework was identified as the best fit as it encourages end users to actively participate in building the product (Gupta, n.d.).The client agreed to the role of product owner, to hold vision of the system and channel knowledge around bed management to the team.

3.1.2 Daily Stand-ups

In the early stages of capturing system requirements, product expectations were varied and requirements were likely to change. Daily stand-up meetings were agreed on to get feedback regularly allowing the project to adapt to change, which helped to reduce time wasted in producing unwanted functionality. Members would answer three questions: What did I accomplish yesterday? What will I do today? (Mountain Goat, n.d.). What obstacles are impeding my progress? Meetings were timeboxed to ten minutes so conversation was concise and no time was lost from the ideal developer working day of 7.5 hours.

3.1.3 Requirements Gathering

Ranges of information gathering techniques were considered to get an understanding of the system. Questionnaires allow targeting a large audience, however their nature of slow response times and the inability for follow up questions would leave uncertainty. Observation of current user interaction was viable but obtaining knowledge was not guaranteed. Strong collaboration with the product owner was considered the most suitable method and by asking open-ended, context free questions, a requirements list was written (Appendix D4). Requirements were prioritized using MoSCoW, and must-have requirements were signed off as minimum viable product, the smallest amount of implementation required to deliver customer value (Cayenne, 2016).

3.1.4 User Stories

In requirements gathering, user stories were derived from the requirements list and written with the product owner, describing functionality of value to users or purchasers of the system. These stories were non-technical, to ensure they could be understood and provided value across the team and not only by developers (Cohn p5). Stories were written independently to one another with annotations. Notes were restricted to minimal detail were possible for stories to remain negotiable rather than finalised software contracts (Cohn p4). Large compound stories, also known as epics, were split into granular user stories enhancing estimation. If stories were difficult to estimate, three questions would be asked: Is there a lack of domain knowledge? Is there lack of technical knowledge? Is the story too big? Developers were sent on spikes for complex stories, which were more difficult to estimate. These timeboxed learning curves involved investigation through research or development (Cohn, p22).

11

To ensure all users stories were testable, non-functional requirements were reworded into functional requirements (Waters, 2008). This allowed for acceptance criteria to be written against each story (Appendix D1).

3.1.5 Role Modelling

A range of users could potentially use the system and so it was important not to write stories from a single perspective (Cohn p32). The Scrum User Role Modelling exercise was carried out to ensure all potential users were considered. The exercise was split into four stages: Brainstorming - Team members independently brainstormed user roles onto cards, a set of attributes that characterize a population of system users. Organising - User roles were compared and overlapped to highlight relationships. Consolidating - Overlapping cards were discussed and duplicates or separate roles were distinguished. Duplicate roles were removed. Refining - Imaginary users were assigned a role and attributes were written for each such as frequency of usage and importance. The potential system users drawn from the exercise were internal bed managers, external bed managers and police. Fictional characters were created for each role and stories were discussed for each characters viewpoint. Defining personas helped push for a system that is fit for purpose for all of its end users (Pichler, 2012).

3.1.6 Sprint Planning

Work was produced in timeboxed development cycles called sprints, each lasting a duration of two weeks allowing time for stories to be implemented and tested (Pomar et.al., 2015, p. 777). It was decided to work in small increments with frequent delivery to embrace regular change requests and adapt software through feedback. Taking a traditional approach may have led to delays in change requests and longer duration before product design was amended (Papadopoulos, 2015, p. 456). Sprint planning sessions were held with the product owner before each sprint. A consensus based estimation technique called ‘Planning Poker’ was used, to estimate each of the user stories. Typically developers would estimate using the Fibonacci sequence, but the team felt this scale of estimation was too high and set the boundaries between 0 and 5. 0 was defined as a trivial task requiring little effort, such as a small text change. 5 was defined for complex tasks, the maximum amount of work involved for a story, requiring research, schema changes and work on the front and back-end of the application. This scale changed though time, starting at 0.5 so no work would go unmissed. Each user story was read aloud and team members revealed their estimates. Members with radically different numbers explained their estimation and stories were re-estimated until consensus was formed. Triangulation, a relative estimation technique was used, taking initial estimates as a base line for estimating new stories (Mayer, 2013). This exercise was beneficial as it made sure the team had the right mind-set of required delivery. The total number of points that the team committed to was recorded as the team’s velocity, a metric used throughout the project to track fluctuations in the quantity of delivery over the period of the project and to determine the workload that the team were capable of delivering in each sprint (Pomar et.al., 2015, p. 776).

12

3.1.7 Kanban Boards

Kanban boards (Appendix C1) were created for prototype and production products to visualise workflow. Initially these were physical boards used only by developers, but to keep a close relationship with the product owner, online boards were created with Trello so activity could be monitored by all team members. New stories brought into the sprint were added to the backlog and upon completing a story a new story was picked from the backlog into ‘In Progress’ and assigned a checklist of developer tasks. The product owner was free to prioritize the backlog at any given time without disturbing the team, as changes made outside of current work shouldn’t impact sprint workflow (Radigan, n.d.). Scrum for Trello was an effective browser extension allowing the team to add estimates and track completion of points per card. As part of the defined Definition of Done (Appendix D2), stories had to be tested on the production server before they could be marked complete. The product owner held the responsibility of moving the story into ‘Done’. New cards were raised for bugs found in testing. These issues were marked with a red label, assigned steps to reproduce the bug and placed into ‘To Do’.

13

4 Product Design A user journey (Appendix F1) was created to assist the product owner with product demonstration. As the project has potential for future development, a README guide (Appendix F2) was written in Git containing instruction for developers to fork the application, setup the project on their local environment and contribute by making a pull request. 4.1.1 UML Modelling

A UML Use Case Diagram (Appendix A2) was created as a visual tool for developers to clarify their understanding of functional requirements with the product owner, without using technical language (Ambler, 2014). Actors, system users or external systems interacting with the system, were added and assigned to a series of use cases, graphically by a continuous line (Dolques p328). Behaviour between use cases or dependency were displayed by dashed lines using ‘include’ or ‘extend’ labels, aiding with the prioritization of tasks. The diagram was successful in highlighting that police did not require additional requirements to bed managers. Having no impact on the minimum viable product, it was decided that the role would not be considered in future sprint planning. A UML Class Diagram (Appendix A3) was created in order to model system entities using classes and attributes. Class methods were defined and symbols were used to indicate the visibility or protection of system components (Pătraşcu, p87). As the system was rapidly changing, it was important for database designers to quickly view a current conceptual data model to make decisions for amendments (Cagiltay, p2184). Therefore Entity Relationship modelling aspects were applied by adding optionality and cardinality between classes. Extreme Programming methodology was applied, when creating diagrams. Team members designed only for functionality that was required at present to complete the task and designs did not cater for future requirements. Future requirements were subject to change and additional detail could result in time wasted (Cusumano, p16). Designs were updated iteratively throughout each sprint and amended as new requirements were gathered.

4.1.2 Usability

Usability standards set by the NHS were explored and researched pointed to User-Centered Design methodology as best practice, which aims to let end-users make UX decisions, rather than developers envisioning user interfaces and adding personal preference (Lowdermilk, p5). In abiding to World Wide Web Consortium’s (W3C’s) Level AA guidelines for accessibility, all NHS software should allow end users to change text size, theme colour and navigate with keyboard controls (NHS England, n.d.). However, the product owner outlined that user interface was not an important aspect to the success of the minimum viable product and that these standards would not be considered. Mock-up designs (Appendix A4) were created for the user interface as part of proof of concept and acquired feedback (Appendix A5) from the product owner in meeting 4 and 5 around layout and branding were implemented.

4.1.3 Responsive Design

The product owner informed that end users would be using the product on desktop and iPad, and so responsive design was required to display the application on 1024x768 and

1200x800 resolutions (Appendix B6). Bootstrap 3 framework was chosen, offering a class

grid system with defined media queries to speed up the development process. Through time, this framework proved to be a bad decision as the predefined breakpoint widths were not always appropriate. Developers created their own set of media queries which was problematic as time was often spent debugging which set of styles were applied. For future

14

development, non-framework mobile first design is recommended to remove the need for column classes in HTML. Developing for smaller devices and scaling up to bigger devices would ensure all resolutions are catered for and help developers utilize space and optimise performance by preventing smaller devices from being overloaded with heavy desktop styling (Zurb, n.d.).

15

5 Product Implementation and Testing

As part of the Definition of Done (Appendix D2), Extreme Programming methodology was used by putting stories through different stages of testing before they could be marked complete and moved on the Kanban board into ‘Done’.

5.1.1 Regression Testing

The product owner’s expectations of the system and system components required were defined by acceptance criteria, written for each user story. Acceptance criteria were added to a regression test script (Appendix D1) and each assigned a series of steps to test the criterion, along with expected test results. For consistency, user names and passwords for the users to test against were stated at the top of each script and all tests were carried out on production server. The ideal workflow would be test on a dedicated user acceptance testing server, and on success deploy to a live environment, but resource was not available. A key was added to indicate the status of each test and when ran, tests were marked clearly with pass or fail. Each test was written independently of system implementation and was written to outline what is expected and not how the software should be implemented (Povilaitis, 2014).

5.1.2 Unit Testing with NUnit

The second stage of testing used test-driven development, were developers translated acceptance criteria into automated unit tests with expected assertions, prior to implementing source code. The technique made developers think about potential problems ahead of time before implementation had started (Besson, p125). The objective was to write as little source code as possible for tests to pass, to stop developers writing unnecessary code. All tests were run repeatedly (Appendix A6) when adding new functionality to ensure previous assertions were still passing. The back-end of the system was composed of separate web projects, including a web layer containing Web API controllers and domain layer containing model entities and repositories (Appendix A7). Using the Repository Pattern enabled decoupling of Web API controllers and business logic, enhancing readability and amenability of code. For data access in the web layer, dependency injection was configured using Autofac, an inversion of control container. Using inversion of control allowed for the web and domain layers to remain decoupled, as repository objects did not have to be instantiated in web API controllers. Instead, repository interfaces were added to the constructors of web API controllers and at run time Autofac resolved dependencies and injected them in (Autofac, n.d.). This separation made it possible to test the domain layer and web API controllers in isolation (Microsoft, n.d.). Moq, a mocking framework was used in unit testing to mimic the context class and return stubbed data when calling repository methods as test code should not be dependent on database implementation detail (Agile Alliance, n.d.). Failing tests were refactored regularly to maintain build stability. Unit tests were effective in finding bugs, which may arguably save time in the long run, but there was a trade-off between test coverage and functionality implemented. It was difficult to justify automated testing to the product owner, as research suggested that 44% of studies conducted had lower productivity in test driven development than test last development (Bissi, p45). Stories could not be marked as complete until they had been manually tested on the production server, and all regression tests passed.

16

5.1.3 Optimisation

The production product utilized latest technology. Bower package manager was used to manage external libraries and through the command line, desired package versions and their dependencies were installed (Bower, n.d.). When developing prototype products, developers found themselves repeating blocks of CSS and hex colours, making it difficult to alter design quickly on request. New requirements were formed to optimize CSS and avoid code duplication, following dry principle (Smith, n.d.). Ruby command line was used to install Sass, a CSS extension to optimise style sheets (Sass, n.d.). For organisation, the original site.css was extracted into separate partial files for each Backbone app, and included with the ‘@import’ directive. Duplicate hex colours were created into variables and repeated blocks of code were made into reusable classes. Grunt.js, a JavaScript task runner was configured to automate the build process (Grunt, n.d.). Two Grunt tasks were set up, ‘grunt’ for local development and ‘grunt build’ for production, which were called by the command line. The first task ran a watcher configured to watch Sass files and on change automatically compile Sass style sheets into CSS. The watcher also watched JavaScript files and on change, JSHint commands were triggered to analyse and detect JavaScript errors, which were reported to developers in command line with jscs-stylish (Appendix A8) (JSHint, n.d.). This method of code review ensured code conformed to style guidelines. Having more than one developer on the project would have benefited the team to identity logical code errors (Atlassian, n.d.). By default, bower packages are pulled into the projects root directory and referencing web packages outside of the web project was not considered organised. A copy step was added to the ‘grunt build’ task to copy packages into the CSS directory of the web project. To reduce time taken for page load, a step was added to minify CSS and HTML, eliminating redundant code and formatting from files without affecting browser output (Google, n.d.). Require.js was used in the Production Project to modularize script dependencies of the front-end application. Rather than polluting the global name space with script tags, a single baseURL with ‘data-main’ attribute was added to index.html to load all required dependencies. Require.js allowed developers to quickly define script dependencies, using short module Ids, without concern about script ordering, as require automatically evaluated scripts in the correct order, using configuration in main.js (Require, n.d.). Marionette.js was used additionally to Backbone.js to use composite application architecture. Business concerns were split into small Marionette Object components e.g. find, booking, isolated from one another and registered in registry.js to form a composite application. Communication between components were made asynchronously with BackBone.Radio, a Backbone event system. The effectiveness of modules is that these building blocks can be used independently, or swapped in and out of future work (Bailey, n.d). In sprint retrospective 1 (Appendix C3), the product owner commented that regression tests were failing. Developers explained that there had been inconsistency with database tables on local and production environments and agreed to start hosting regularly on the production server. A database layer was created on the server-side and DbUp library was added to help track changes made to the SQL database (DbUp, n.d.). Folders named Scripts and Seeds were added, containing SQL scripts marked with version numbers. On Debug > Start New Instance, the console application executes the SQL scripts and tracks changes made by creating a record in the SchemaVersion table. It effectively informs developers if migrations were successful and logs errors to the console in red text (Appendix A9).

17

6 Product Evaluation The product owner considered the product a success, as all stories considered as minimum viable product were complete. To meet the functional requirement, unauthenticated users cannot use the system and are redirected to the login view when attempting to access protected content (Appendix B7). This functionality was written using ajaxComplete function, which checks the HTTP status code returned from the back-end server and classes the user as unauthorised for codes 401, 403 and 400. In retrospect, better implementation would be to check if the ‘accessToken’ cookie containing the bearer token is set, before requests are made to the back-end server to reduce network traffic and load time between views. The homepage for prototypes and production product includes a form allowing users to authenticate with their username and password (Appendix B8). In sprint planning it was agreed that functionality allowing private bed providers to sign up was out of scope and prioritized as a won’t-have requirement as it was not important for the success of a minimum viable product. NHS and private organisation users can amend their personal details (Appendix B9) and view their organisation detail, which is pre-set on login for security purposes (Appendix B10). There is potential to implement a management portal, so users can be assigned to an organisation using a web interface, rather than relying on database administrators to make changes. Investigation into roles based systems would be required. If the application were to expand and integrate with NHSmail, internal providers would be able to register and be assigned to their organisation through the portal. Background checks could be made on external providers before they’re granted access to the system. During sprint 1 of the production product, the initial search view was implemented using Google Map API to display a 2D map, with the default location set to the user’s organisation (Appendix B11). This task was estimated as 3 points, or one developer day. However developers were unable to remove the Authentication header that had been pre-set for requests using ajaxPrefilter, as part of proof of concept and so requests to Google Maps to display a map and geocode the GP postcode were failing. Unallocated time was consumed researching, although suggestions to set the Authorization header to null, did not work. This design flaw resulted in a large rewrite of the back-end server, setting an authentication cookie on the server-side rather than the client. Developers spent 5 days to complete this story, equating to eight story points. At the end of the sprint, Story #3 was incomplete, as it had not been tested. Underestimation was recorded as an impediment (Appendix C3) and to resolve the issue it was agreed that the amount of time required to research a task should be factored into story estimation (Appendix D3). Bed Managers can search for a patients bed by constraints such as gender (male, female, both), tier (low, medium, high, all), postcode of patients GP, distance of search results (25, 50, 100, 300 miles) and age. As requested, users can tick a checkbox to search by all ages or a specific age using a date picker (Appendix B12). JavaScript was written to calculate and validate the age from date selection. A GET request is made to Google Maps Geocoding API with the input postcode, and the JSON response containing the geocoded longitude and latitude are set in a Search model. A POST request is made to the API endpoint ‘organisations/search’ along with the search constraints in an object matching the controllers OrganisationSearchDto parameter. Data Transfer Objects were used throughout the application to transfer aggregated data across network. Grouping attributes into one class object enhanced performance by reducing the number of network calls to one single call

18

(Microsoft, n.d.). For future development, a library such as AutoMapper is advised to reduce time spent manually mapping entity framework objects to DTOs by hand (Automapper, n.d.). The Search method in OrganisationRepository.cs finds available beds listed by other organisations matching the constraints and returns them in a collection of OrganisationLocationDtos. To find beds within the requested mileage, spatial indexing was researched and Microsoft’s DbGeography class was identified to work with a geodetic coordinate system (Microsoft, n.d.). Organisation postcodes were provided by the product owner and manually geocoded using an external web service (Appendix B13). The geocoded longitudes and latitudes were used to create point objects and stored in the database as a Geography field type. The FromText method of DbGeography class is used by the Search repository method, were metres returned by the method are converted to miles before checking if the bed is in range. The top 4 results are marked on the map along with a results list, ordered by ascending distance then by price. Click actions were added to map markers and on selection, the opacity of the marker changes and the associated result item is highlighted. In sprint 2, a bug was raised for duplicate markers overlapping on the map for beds at the same location. This was resolved by displaying one marker and on selection, multiple result items at the selected coordinate are highlighted (Appendix B14). A ‘Make Booking’ URL is present on each result list item and on selection the user is taken to a booking request view with an overview of the selected bed (Appendix B14). As sensitive data cannot be held in the system, bed managers can request a patient bed by entering their unique ten digit Patient Identifier and optionally add non-clinical notes. A checkbox is included on the form for the requester to inform that clinical notes will be sent separately using NHSMail. Email addresses for Bed Managers in the organisation advertising the bed are listed. After submitting a booking request, the user is directed to a view displaying all requests associated with their organisation ordered by date descending. A setSortField function was written in request-collection.js to sort the Backbone.Collection by any specified field. A chevron icon is placed next to the Date / Time column in the request table and when clicked, the dateSort function in booking.js is called. This function changes the direction of the chevron with jQuery, by applying a different CSS class, and uses the bookingRequestChannel to trigger the sort event, passing the string ‘dateRequested’ to reorder the collection by date (Appendix B15). Further functionality was added to filter between all, incoming or outgoing requests, achieved by passing each models status attribute to Backbones ‘where’ collection function (Appendix B16). All filtering was done on the client side to optimise the application by reducing the amount of network calls. In sprint 2, a bug was raised informing that search criteria was lost when navigating between views to amend the search, using browser navigation buttons. Browser navigation had not been considered and the application had only been tested using the UI. To change state, the front-end used Backbone.History, a global router, passing in a route and object containing an attribute named ‘trigger’, set to true to trigger routing asynchronously, without updating the URL (Backbone, n.d.). As a result, the Backbone model state was lost on hard browser refresh or by going to the results view directly without selecting bed constraints. To resolve this issue, the application was restructured to drive navigation through the URL. JavaScript’s Window.location object was used to append the URL, passing in constraints stored in the Backbone Search model along with a noun describing the constraint, conforming to restful resource naming standards (Appendix B17). On view initialization, the URL string was parsed and decoded into variables, which were used to populate the model.

19

7 Project Evaluation Before the project could go underway, a risk assessment was carried out (Appendix C4) and participants were asked to sign a consent form (Appendix C5).

Various methods of project management were used in order to ensure all objectives were met. For general organisation, scheduled meetings were recorded in a communication schedule (Appendix C6), a history of project documentation and amendments made were logged (Appendix C7) and a revision numbering system was used for file version control (Appendix C8). For personal planning, Google Keep was used to store reminders for development and document tasks which did not need to be shared across the team via the Kanban board. Notes were assigned colours and tags to mark the status of each task (Appendix C9). Although agile methodology was chosen over traditional methodology, using a Gantt chart (Appendix C10) was an effective way to visualise project milestones and deadlines for other projects. In was agreed in requirements gathering that sprints would last a duration of two weeks and the ideal developer working day is 7.5 hours. Having estimated user stories, it was important to calculate the actual time taken to complete each task. Projects were set up in Harvest for both proof of concepts and user stories were imported (Appendix C11). Harvest allowed developers to record time spent on each task and at the end of each sprint generated reports and charts were analysed to compare estimates against actual time taken. This tool was effective as it gave the product owner an insight to how much development could be produced over the next 3 sprints for the production product and using this measurement, the requirements list (Appendix D4) and project plan (Appendix E1) were revisited, forming a minimum viable product. In Agile, it is considered mandatory for the product owner to write and smoke test the system, to catch bugs while developers modify software (Lakshminarayan, 2013). However in sprint retrospective 2 (Appendix C3), the product owner stated their absence for the next sprint and so this responsibility was given to developers. Although this work was factored into estimation, it had a negative impact on the project as it meant that developers didn’t have as much time write automated tests, which would make future testing less time-consuming and allow for more frequent testing (Hudson, n.d.). As a result, the non-functional requirement of 70% unit tested code coverage was not met and automated browser tests using Specflow were only written for the login view (Appendix A10). Meetings held fortnightly with the project supervisor were documented (Appendix C12) so all guidance and feedback were implemented and not forgotten. Research suggested that daily stand-ups should not be recorded as by nature they are not a planning session and so no new requirements are formed (Gupta, 2014). However short notes were recorded and shared when the product owner was absent, to maintain strong collaboration and cooperation between developers and stakeholders (Waters, 2007). Sprint retrospectives were attended by the product owner and developers at the end of each sprint to inspect and adapt the team’s performance (Microsoft, n.d.). To ensure improvements could be made, all team members were asked to participate in the Starfish exercise (Appendix C13), an agile technique expanding on the three typical retrospective questions that often lead to vague and intertwined answers: What went well? What went wrong? What can be improved?

20

Instead throughout each sprint, team members wrote down tasks that they should start, stop, keep, do more and do less of (Gonçalves, n.d.). In the retrospective session, these notes were placed on a flip chart, leading to group discussion. The exercise was successful in forming a set of retrospectives that the team could use to improve their work, and by highlighting positive aspects of the project, team moral was boosted. As Scrum Master, it was the author’s responsibility to summarize planning sessions (Papadopoulos, 2015, p. 458). End of sprint reports were written during the production product, to measure if the project was on track and the efficiency of the team using metrics such as velocity (Atlassian, n.d.). Each report contained a series of objectives, sprint goals and sprint highlights, which were discussed at subsequent meetings to see if objectives were met. Reports contained a table of sprint user stories, their estimated values and status. An end of sprint status was written with a summary of the team’s velocity, informing the product owner of how many stories were completed per day. It is clear that developer’s estimation skills improved over time. In the first sprint developers committed to 14 points worth of stories, however only 11 points were moved into done. 11 points were added to the backlog in sprint 2 and this velocity was achieved. In sprint 3, the team committed to 14 points all of which were implemented and tested, suggesting that developers will be able to complete 1.4 points per day in future development. Impediments were recorded in each report and assigned a status, to ensure these blockers were acted upon. Git was identified as the most suitable form of version control, because of its branching model. Developers used feature based workflow, checking out new branches (Appendix A11) when developing functionality and merging commits into master branch (Appendix A12) when complete (Git, n.d.). This was effective, allowing developers to experiment and dispose of code without breaking the build. To complete the skills audit (Appendix D5) P4Merge tool was set up to visualise code changes (Appendix A13), and is encouraged for future development to merge pull requests from contributing developers (Performance, n.d.). Training was required to squash multiple commits into single commits with the intention of keeping a cleaner repository but admittedly these skills were not applied to the production product. In proof of concept sprint 1, cloud based services such as AppHarbor were tested, but affordable hosting packages were not suitable for the project due to restricted database permissions and limited resources reducing application performance. The decision to self-host was made, and time was allocated for developers to setup Windows Server on a remote machine, with SQL Server Management Studio and IIS. For security, user accounts were created per project and permissions were added to each of the web project directories. These credentials were added in IIS to grant access to the web projects (Appendix B18). Hosting projects on the live environment was challenging. Attempts were made to copy files from local machine to remove server using drag and drop, cut and paste and command line with Robocopy command (Microsoft, n.d.). Windows estimated several days for file transfer and attempts timed out. Project files were also too large to transfer using affordable cloud services. Developers resorted to setting up a development environment on the remote server, so source code could be pulled from GitHub and built in Visual Studio. This was not an elegant solution as each commit required restoration of NuGet packages, configuration of port numbers in Web.config and amending site bindings in IIS before the project could be built. For future development, it is advised to automate the build process using One-Click Publish in Visual Studio, which automatically deploys to IIS using database and Web.config configuration, set in a publish profile (Microsoft, n.d.). Unfortunately automation had not been considered at the time of development and this may have been identified early on if technical advice was obtained from the project supervisor prior to starting the sprint.

21

8 Summary The project was successful as all tasks marked as minimum viable product were complete in order to deliver a secure single-page application that enhances patient care by sharing patient bed availability across the NHS and with private care providers. A clear set of objectives were defined at the beginning of the project and maintained throughout, to help steer the focus of work and measure the project’s success. To complete all objectives, initial research into the NHS was undertaken through interviews with an NHS bed manager, who was assigned the role of product owner. Sprint planning sessions were held with the product owner to form a set of functional and non-functional requirements which were estimated and prioritized using agile methodology.

Practical experimentation was carried out to explore different architectural patterns used for web applications, authentication approaches, frameworks and their flexibility of view engines in order to make recommendations for the production product. Single-page applications were chosen over traditional multi-page applications, being the faster application to fetch data and render views in the browser using asynchronous JavaScript.

Sprint planning and retrospective sessions were held to refine requirements and analyse team performance, to estimate and create a list of user stories that could realistically be achieved within a set time frame over three sprints, forming a minimum viable product. Having been put through rigorous testing, the production product is accessible for demonstration on a live environment, internally hosted running on Windows Server with IIS.

Unlike .NET MVC framework, Backbone.js did not offer a server-side solution. Findings from literature review suggested that the best way to implement authentication between front-end applications and server-side APIs was by setting a cookie on the client-side containing the authorization token sent from the server. This approach led to one of two successful prototype products allowing Bed Managers to authenticate and update their personal details. However in future sprints impediments were met when developers were unable to remove the Authorization header set with ajaxPrefilter, resulting in failing requests to Google Map API. Unallocated time was spent tackling the problem, by restructuring the application to set the cookie on the server-side. This large rework impacted the delivery of production product sprint 1 as stories were left incomplete. The design flaw however did not hinder the success of the project as a whole. The suitably adopted agile methodology allowed for problems to be detected early, stories to be reprioritized and new work factored into original estimates.

For future development, the next logical step would be to allow bed managers to accept and reject incoming booking requests. As the project stands, the role ‘Bed Manager’ is hardcoded into the claims identity and isn’t currently used. Research around roles based authentication is required, to identify the most suitable architectural approach to set user permissions. This piece of work offers potential to implement a management portal, which would allow users with special permissions to manage an organisation through a web interface, rather than relying on database administrators to make changes.

22

9 Appendices Project documentation and supporting evidence can be found at: <https://www.dropbox.com/sh/21gdq82kw63dw4v/AADBzgd2AR8fNboyQSnl17rQa?dl=0> Project source code can be found at: <https://github.com/joehoughton/proof-of-concept-mvc> <https://github.com/joehoughton/proof-of-concept-spa> <https://github.com/joehoughton/production-project>

23

9.1 Appendix A

9.1.1 Appendix A1: Wireframe Designs

24

25

9.1.2 Appendix A2: UML Use Case Diagram

26

9.1.3 Appendix A3: UML Class Diagram

27

9.1.4 Appendix A4: Mock-up Designs

Login View

Organisation Detail View

28

User Detail View

Find View 1/3

29

Find View 2/3

Find View 3/3

30

Booking Request View

Manage Bookings View

31

9.1.5 Appendix A5: Mock-up Design Feedback

32

9.1.6 Appendix A6: NUnit Unit Testing

The simplest example using Moq to mock DbSet classes and a repository method using stubbed data.

33

9.1.7 Appendix A7: Server-side Separation

34

9.1.8 Appendix A8: JsHint and JSCS-Stylish

35

9.1.9 Appendix A9: DbUp Console Application

Migration error messages

Migration success messages

36

9.1.10 Appendix A10: Specflow Automated Browser Testing

37

9.1.11 Appendix A11: Git Branches

Proof of Concept MVC

Proof of Concept SPA

Production Product

38

9.1.12 Appendix A12: Git Commits

Proof of Concept MVC

Proof of Concept SPA

Production Product

39

9.1.13 Appendix A13: P4Merge Merge Tool

40

9.2 Appendix B

9.2.1 Appendix B1: Form Validation

41

9.2.2 Appendix B2: OAuth Bearer Tokens

Request bearer token and refresh token.

42

9.2.3 Appendix B3: Refresh Tokens

Request bearer token with longer expiration date by posting received refresh token.

43

9.2.4 Appendix B4: Token Storage

Received bearer token stored in a cookie, set in local storage.

44

9.2.5 Appendix B5: Experimentation Results

45

Proof of Concept MVC: Login View

Proof of Concept SPA: Login View

46

Proof of Concept MVC: User Detail View

Proof of Concept SPA: User Detail View

47

Proof of Concept MVC: Organisation Detail View

Proof of Concept SPA: Organisation Detail View

48

Proof of Concept MVC: Organisation Detail View Update

Proof of Concept SPA: Organisation Detail View Update

49

9.2.6 Appendix B6: Responsive Design

iPad 1024x768

Desktop 1200x800

50

Mobile 360x640

51

9.2.7 Appendix B7: Protected Resource

Accessing a protected resource without authorization or organisation privileges will redirect the user to the login view and display a warning.

9.2.8 Appendix B8: Authentication

52

9.2.9 Appendix B9: User Detail

9.2.10 Appendix B10: Organisation Detail

53

9.2.11 Appendix B11: Find Beds

54

9.2.12 Appendix B12: Search by Care Requirements

Search beds by all ages, both genders, all tiers and default distance of 25 miles.

Search bed by specific age (calculated from date), gender, tier and distance.

55

9.2.13 Appendix B13: Geocoded Locations

56

9.2.14 Appendix B14: Search Result Selection

Displaying a single marker and highlighted results for beds at the same location.

57

9.2.15 Appendix B15: Booking Request Sort

Booking requests sorted by date / time descending.

Booking requests sorted by date / time ascending.

58

9.2.16 Appendix B16: Booking Request Filter

59

9.2.17 Appendix B17: URL Decoding

Find view URL prior to search

Find view URL searching with default bed constraints

Find view URL searching with specific constraints

Populating the Backbone model with decoded URL parameters

60

9.2.18 Appendix B18: IIS Permissions

61

9.3 Appendix C

9.3.1 Appendix C1: Trello Kanban Boards

<https://trello.com/b/Z5PEurxr/proof-of-concept-spa-sprint-1-1> <https://trello.com/b/ClAYi2wJ/proof-of-concept-mvc-sprint-1-1> <https://trello.com/b/DzmqHwsn/production-project-sprint-1-3> <https://trello.com/b/bzRdWd42/production-project-sprint-2-3> <https://trello.com/b/WWl5KkkR/production-project-sprint-3-3> User stories and bugs raised, along with their estimated time and actual time taken.

A checklist of developer tasks assigned to each user story.

Communicating through Trello to raise bugs.

62

Raising bugs on the board with a custom label.

Adding steps to reproduce each bug.

63

9.3.2 Appendix C2: Product Owner Meeting Minutes

Product Owner Meeting Minutes Date Reviewed: 26/10/2015

Meeting Number: 1

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 26/10/2015, 11am

Actions agreed at previous meeting (completed or comment):

First Meeting

Meeting findings:

1 No clinical data will be exchanged using the system, to ensure there are no Information Governance complications.

2 Potential system users: - Bed Managers in an NHS hospital (public sector) - Bed Managers in private institutions (private sector) - Officers in a law enforcement agency - Police (to refer a patient to a ward)

3 Booking requests can be made by users seeking a bed internally and externally. Requests can only be made in the UK.

4 Two organisations may be based at the same location, or share a ward. Bed prices on the same ward can vary depending in the organisation.

5 Bed Managers alternate between day and night shifts, and leave a paper based hand over for the next member of staff.

6 Bed Managers making bed bookings comminute via telephone.

7 There are different types of organisations, including Mental Health, Community Care, Acute and Police.

8 Wards can have certain constraints, including Age (e.g. 18-65) and Gender (e.g. female only maternity wards).

9 There different types of beds including paediatric, geriatric, surgical and medical.

10 Some beds in the public sector are not available to the private sector.

11 Bed Managers booking a bed aim to find one closest to the patients GP, although this is not always possible.

12 NHS staff communicate using NHSmail email addresses to send clinical data securely to private care providers.

Next meeting: 26/10/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to produce a requirements list based on the findings of the meeting.

2 PO to produce a list of organisation postcodes. PO to bring any paper work related to bed bookings, which may aid the understanding of how the NHS operates.

64

Product Owner Meeting Minutes Date Reviewed: 03/11/2015

Meeting Number: 2

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 02/11/2015, 11am

Actions agreed at previous meeting Status

1 JH to produce a requirements list based on the findings of the meeting.

Complete

2 PO to produce a list of organisation postcodes. PO to bring any paper work related to bed bookings, which may aid the understanding of how the NHS operates.

Complete

Meeting findings:

1 Not all users of the system will have NHSMail, and so a user should be able to authenticate with a username or standard email address. PO has no preference for the final implementation.

2 The primary users of the system will be both private and non-private Bed Managers.

3 It is not important for police to use the system. The main focus of the product will be finding and booking a bed. Police often refer patients to a different ward, but are not involved with the booking requests.

4 PO agreed that SMS alerts around booking requests will not be required, as funding will not be provided. Email alerts are a nice-to-have feature but not a must-have.

5 Hospital wards can have different types of beds. PO confirmed the types to be used in the system are Paediatric, Geriatric, Medical and Surgical.

6 It is desirable for a bed manager to change their contact details. For security reasons, they should not be able to change the organisation they belong to. This should be pre-set on login. For this reason, users will not be able to register to the system.

7 Search results should be ordered by beds closest to the patients GP in miles.

8 Bed types will have constraints such as Age, Gender and Tier. Search requirements must match these constraints. Exceptions cannot be made through the system e.g. adult staying at a young person’s ward.

Next meeting: 26/10/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to bring a deck of cards to next meeting for Planning Poker

65

Product Owner Meeting Minutes Date Reviewed: 03/11/2015

Meeting Number: 3

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 03/11/2015, 11am

Actions agreed at previous meeting Status

1 JH to bring a deck of cards to next meeting for Planning Poker. Complete

Meeting findings:

1 JH and PO agreed the ideal development working day is 7.5 hours.

2 JH and PO agreed each developer sprint will last a duration of 2 weeks.

2 JH and PO agreed on the following scale to estimate each user story, based on the complexity of the use case: Value: 1-5 Rating: Easy, Simple, Medium, Complex, Very Complex Developer effort in days: 0.25, 0.75, 1, 2, 4

3 JH and PO wrote a list of user stories to capture the system requirements, from the perspective of the user requiring functionality. Large epics were broken down into granular user stories.

4 JH and PO played Planning Poker to estimate each user story. Estimation was repeated and debated until a consensus was formed. User stories were recorded in User Stories 0.1.

5 User Stories were prioritized using MoSCoW prioritization technique.

6 JH committed to a total of 10 story points for each prototype product, totalling 8 developer days. The remaining 2 days would be used for project setup and hosting. The stories to be implemented for the prototype products were recorded.

7 PO confirmed bed managers will not be able to add, edit or delete wards because giving all users this level of authority is potentially dangerous.

8 PO confirmed that ward is the preferred word over facility.

Next meeting: 30/11/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to add user stories and developer tasks to existing Trello Kanban boards and provide a link to PO so progress can be monitored.

66

Product Owner Meeting Minutes Date Reviewed: 30/11/2015

Meeting Number: 4

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 30/11/2015, 11am

Actions agreed at previous meeting Status

1 JH to add user stories and developer tasks to existing Trello Kanban boards and provide a link to PO so progress can be monitored.

Complete

Meeting findings:

1 PO was satisfied with the design and confirmed the font size was readable.

2 PO requested that the notification alerts should have a set timeout.

3 There was a small loading time for both applications on login. PO requested a loading icon to be present on each request, to indicate that the application is performing an action.

4 PO asked to remove spacing on the drop down navigation.

5 PO recommended that the colour blue (#022144) should be used, along with the colour green (#BBCC34), so remain consistency with colours used in the NHS.

6 PO and JH established a Definition of Done, a set of requirements that must be met before a user story can be marked as complete. In order for a story to be complete, it must meet the following conditions:

Pass code review by JH

Be accessible on the production server

Pass unit and integration testing

Acceptance tested (by PO, JH or Automated were possible)

UI design approved by PO

7 PO and JH played Planning Poker to re-estimate user stories to factor in testing time for each story. The added points reflects the effort of both PO and JH.

8 JH and PO agreed that tasks marked as ‘Must have’ form the minimal viable product.

9 PO and JH calculated that JH had completed a total of 14 story points for each prototype product, including setup. A total of 10 developer days. JH feels that the velocity of 14 is achievable in the next sprint, but could not commit to any more story points as development was carried out for the duration of the sprint.

10

PO and JH added 14 points worth of user stories to the backlog of the Production Product Sprint 1/3 Kanban board, to be implemented in the next sprint.

Next meeting: 30/11/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to create mock-up designs for each of the minimum viable product views.

2 PO to write acceptance criteria for the next sprint.

67

Product Owner Meeting Minutes Date Reviewed: 2/12/2015

Meeting Number: 5

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 1/12/2015, 11am

Actions agreed at previous meeting Status 1 JH to create mock-up designs for each of the

minimum viable product views.

Complete

2 PO to write acceptance criteria for the next sprint. Incomplete

Meeting findings:

1 JH and PO discussed mock-up designs. JH asked PO if there were any accessibility requirements for the system. PO confirmed that the UI of the system does not need to cater for those with disability. The primary language of the system will be English and the use of magnifiers, voice recognition and audio commands are not required. JH agreed that although these areas are important aspects of design, they are out of scope and not high level requirements to meet the minimum viable product.

2 PO confirmed find-bed-view 0.2 was the best design to be implemented.

3 PO stated that all references to age should be recorded as "DOB" as it's more apparent. PO asked for the field to be a date picker in DD/MM/YYYY format that would calculate the user’s age. This functionality was added to the backlog of the Kanban board and estimated in Planning Poker.

4 As mentioned in email, PO asked for gender, bed tier and distance fields to be a select list with the following values: Gender – Male, Female, Both (Default) Tier – Low, Medium, High, All (Default) Distance – 15, 25 (Default), 50, 100, 300 This functionality was added to the backlog of the Kanban board and estimated in Planning Poker.

5 PO said the heading background colour should be blue (#022144) and navigation buttons, toggles green (#BBCC34).

6 PO did not bring acceptance criteria to the meeting. JH outlined the importance of defining boundaries for each story, and so paired with PO to write the list. The acceptance tests were added to the Regression Test Script.

Next meeting: 04/01/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to add new tasks to the backlog of the Kanban board.

2 JH and PO to write down their thoughts throughout the sprint on sticky notes, and consider if they fall into the following categories:

Start

More

Keep

Less

Stop accaessibility

68

Product Owner Meeting Minutes Date Reviewed: 03/01/2016

Meeting Number: 6

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 01/01/2016, 11am

Actions agreed at previous meeting Status

1 JH to add new tasks to the backlog of the Kanban board. Complete

2 JH and PO to write down their thoughts throughout the sprint on sticky notes, and consider if they fall into the following categories:

Start

More

Keep

Less

Stop

Complete

Meeting findings:

1 JH and PO discussed the end of sprint report provided by JH. PO was pleased that the production product environment had been set up for testing, but stated they would not have much time in future sprints to write acceptance criteria or complete regression test scripts. PO agreed JH would be responsible for testing in future sprints, and this time would be factored into estimation.

2 The current velocity of the team is 11 story points. Therefore, 11 points worth of stories were added to the backlog of the Kanban board. The following story was incomplete at the end of the sprint: As a Bed Manager I want to see all wards and beds within a specified mile radius so that I can find a bed within suitable range This story was re-estimated to 2 points as it still needed testing. PO made this task the highest priority.

3 JH and PO used the agile Starfish exercise, taking it in turns to place their sticky notes on the flipchart. Each point raised was recorded by JH and sprint retrospectives were formed.

4 JH and PO reviewed the current testing criteria in the regression test script and agreed it was up to date.

Next meeting: 04/01/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to add new tasks to the backlog of the Kanban board.

2 JH to add sprint retrospectives to end of sprint report.

3 JH and PO to write down their thoughts throughout the sprint on sticky notes, and consider if they fall into the following categories:

Start

More

Keep

Less

Stop

4 JH to write acceptance criteria and regression test scripts.

69

accaessibility

Product Owner Meeting Minutes Date Reviewed: 16/01/2016

Meeting Number: 7

Attendees: Joe Houghton, JH Product Owner, PO

Date / Time Meeting: 15/01/2016, 11am

Actions agreed at previous meeting Status

1 JH to add new tasks to the backlog of the Kanban board. Complete

2 JH to add sprint retrospectives to end of sprint report. Complete

3 JH and PO to write down their thoughts throughout the sprint on sticky notes, and consider if they fall into the following categories:

Start

More

Keep

Less

Stop

Complete

4 JH to write acceptance criteria and regression test scripts. Complete

Meeting findings:

1 JH and PO discussed the end of sprint report provided by JH.

2 All stories were completed in the sprint, including task #1 that was re-estimated as 2 points, having failed to test it in the previous sprint. This task was made priority and completed first. The current velocity of the team remained at 11 story points. The team worked without interruptions for 10 developer days, equating to 1.1 point per day. However, PO and JH agreed that rather than adding 11 points worth of new stories to the board, only those considered as MVP would be added. This would leave JH time to write documentation and ensure the system is stable before release. These tasks were estimated and added to the backlog of the Kanban board.

3 JH and PO used the agile Starfish exercise, taking it in turns to place their sticky notes on the flipchart. Each point raised was recorded by JH and sprint retrospectives were formed.

4 PO approved the regression test script provided by JH, which included new acceptance criteria.

5 PO may not be available throughout the next sprint. JH will still hold daily stand-ups and notes will be fed back to PO.

Next meeting: 04/01/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to add new tasks to the backlog of the Kanban board.

2 JH to add sprint retrospectives to end of sprint report.

3 JH and PO to write down their thoughts throughout the sprint on sticky notes, and consider if they fall into the following categories:

Start

More

Keep

Less

Stop

4 JH to write acceptance criteria and regression test scripts.

70

accaessibility

9.3.3 Appendix C3: End of Sprint Retrospective Reports

End of Sprint Report 1 – Production Product Date Reviewed: 04/01/2015 Sprint: 1 Kanban Board: <https://trello.com/b/DzmqHwsn/production-project-sprint-1-3>

Table of Contents

1 Objectives ........................................................................................................71

2 Sprint Goal .......................................................................................................71

3 Sprint Highlights ...............................................................................................71

4 Original Sprint Scope / End of Sprint Status ....................................................72

5 Developer Team Resource Profile ...................................................................72

6 Impediments ....................................................................................................73

7 Retrospectives .................................................................................................73

71

1 Objectives

The objectives of this document are:

To highlight the main successes of the Sprint

Report on the outcome of the Sprint against the defined Sprint Goals

To access time spent against story points delivered in order to estimate the team velocity for the Sprint

Identify the impediments encountered during the Sprint and how they are resolved (or planned to be resolved)

2 Sprint Goal

The Sprint goal defined for the sprint is:

To setup the production server

To setup the production database

3 Sprint Highlights

The following highlights have been recorded against the Sprint:

The setup the production server was successful

The setup the production database was successful

72

4 Original Sprint Scope / End of Sprint Status

The following stories were identified as in scope at the beginning of the project. The following table shows the list of stories from this Sprint including their story point and status information.

Trello ID

Summary Issue Type

Story Points

End of Sprint status / Team

Velocity

#4 Project Setup Setup 3 Complete

#1 As a Bed Manager I want to enter the postcode or address of the patients GP so that the area of the practice is displayed on the map and the GP location is marked

Story 3 Complete

#2 As a Bed Manager I want to enter the patients age and select their gender to search for suitable beds available that match the requirements are marked on the map

Story 5 Complete

#3 As a Bed Manager I want to see all wards and beds within a specified mile radius so that I can find a bed within suitable range

Story 6 Incomplete

Total 17 11

In this sprint, the team was not able to complete all of the tasks. JH had committed to 14 points worth of stories, however only 11 points were moved into done. JH had estimated story #1 to be 3 points or 1 developer day. However, JH found difficulty removing the Authentication header that had been pre-set for requests using ajaxPrefilter and so requests to Google Maps were failing. As a result, JH had to research and find a solution to this problem, which resulted in a large restructure to the back-end server, setting an authentication cookie on the server side rather than the client. JH spent 5 days to complete this story, which equates to 8 story points. 5 story points over the original estimate.

Story #3 was uncomplete at the end of the sprint as it had not been tested. The story will be re-estimated and reprioritized in the next sprint.

5 Developer Team Resource Profile

The following table shows days recorded by the team:

Name Days Worked on Sprint

Joe Houghton, JH 10

Total 10

73

6 Impediments

Blockers: There are no blockers to report.

The following impediments were noted in the Sprint:

Impediment Improvement Identified to resolve Status

Underestimation of the tasks that can be completed during the sprint which meant that not all stories could be completed.

The amount of time required to research a task should be factored into story estimation. Researching areas of uncertainty may reduce time spent on a task and prevent developers having to rewrite code.

Closed

7 Retrospectives

74

Start

Prioritising manual testing

Frequent releases to the production server for testing

Self-code review

Paying attention to what is being pushed to git. Update git ignore file regularly. Stop

Communicating via telephone and use the Trello Kanban board were possible Keep

Daily stand-up meetings to discuss progress

Adding relevant messages to git commits

Working on a different git branch for each user story More of

Raising bugs on the Trello Kanban board Less of

Time stuck on a task before asking tutors for guidance

75

End of Sprint Report 2 – Production Product Date Reviewed: 15/01/2015 Sprint: 2 Kanban Board: <https://trello.com/b/bzRdWd42/production-project-sprint-2-3>

Table of Contents

1 Objectives ........................................................................................................76

2 Sprint Goal .......................................................................................................76

3 Sprint Highlights ...............................................................................................76

4 Original Sprint Scope / End of Sprint Status ....................................................77

5 Developer Team Resource Profile ...................................................................77

6 Impediments ....................................................................................................78

7 Retrospectives .................................................................................................78

76

1 Objectives

The objectives of this document are:

To highlight the main successes of the Sprint

Report on the outcome of the Sprint against the defined Sprint Goals

To access time spent against story points delivered in order to estimate the team velocity for the Sprint

Identify the impediments encountered during the Sprint and how they are resolved (or planned to be resolved)

2 Sprint Goal

The Sprint goal defined for the sprint is:

To communicate more through Trello

To be able to search for beds by constraints

3 Sprint Highlights

The following highlights have been recorded against the Sprint:

Communication through the Trello Kanban board was stronger than the previous sprint. Bugs were raised as a separate task and added to the backlog.

All stories have been completed and moved into done

77

4 Original Sprint Scope / End of Sprint Status

The following stories were identified as in scope at the beginning of the project. The following table shows the list of stories from this Sprint including their story point and status information.

Trello ID

Summary Issue Type

Story Points

End of Sprint status / Team

Velocity

#1 As a Bed Manager I want to see all wards and beds within a specified mile radius so that I can find a bed within suitable range

Story 2 Complete

#2 As a Bed Manager I want to search with specific bed constraints so that I can find the most appropriate beds available

Story 3 Complete

#3 As a Bed Manager I want to view search results closest to the GP location on the map including the distance from the GP and bed price so that I can request a suitable bed

Story 3 Complete

#4 As a Bed Manager I want to make a booking request for a bed, so that I no longer have to make a telephone call to other bed managers

Story 3 Complete

Total 11 11

Incomplete task #1 from the previous sprint was re-estimated from 6 to 2 points and given the priority level of high. This task was completed before development started on new tasks added to the board. All stories were implemented and tested, meaning the teams velocity remained at 11. The sprint latest for 10 developer days without interruption and so 1.1 points worth of tasks were completed per day.

5 Developer Team Resource Profile

The following table shows days recorded by the team:

Name Days Worked on Sprint

Joe Houghton, JH 10

Total 10

78

6 Impediments

Blockers: There are no blockers to report.

The following impediments were noted in the Sprint:

Impediment Improvement Identified to resolve Status

PO may be unavailable throughout the next sprint.

JH will complete daily stand ups on his own. Notes will be recorded and fed back to PO when available.

Closed

7 Retrospectives

79

Start

Frequent and smaller commits were possible

Manual testing on local machine before hosting in the production server Stop

Forgetting to run grunt to check for JSHint errors

Spending time looking at tasks outside MVP to prevent scope creeping Keep

Working on new feature branches for different stories

Thinking of previous retrospective points to improve performance More of

Revisiting SCSS stylesheets to make use of sass classes, following DRY principle

Time spent fixing older test scripts

Visibility of work. Other tasks should be considered when developing so blockers are not hit.

Less of

Uncertainty going into a sprint. Ensure necessary questions are asked at sprint planning so development can start without further questions.

80

End of Sprint Report 3 – Production Product Date Reviewed: 29/01/2016 Sprint: 3 Kanban Board: <https://trello.com/b/WWl5KkkR/production-project-sprint-3-3>

Table of Contents

1 Objectives ........................................................................................................81

2 Sprint Goal .......................................................................................................81

3 Sprint Highlights ...............................................................................................81

4 Original Sprint Scope / End of Sprint Status ....................................................82

5 Developer Team Resource Profile ...................................................................82

6 Impediments ....................................................................................................83

7 Retrospectives .................................................................................................83

81

1 Objectives

The objectives of this document are:

To highlight the main successes of the Sprint

Report on the outcome of the Sprint against the defined Sprint Goals

To access time spent against story points delivered in order to estimate the team velocity for the Sprint

Identify the impediments encountered during the Sprint and how they are resolved (or planned to be resolved)

2 Sprint Goal

The Sprint goal defined for the sprint is:

To ensure all regression tests are passed

To be able to view and filter internal and external booking requests

3 Sprint Highlights

The following highlights have been recorded against the Sprint:

A setup guide is created to aid future developers

All stories have been completed and moved into done

82

4 Original Sprint Scope / End of Sprint Status

The following stories were identified as in scope at the beginning of the project. The following table shows the list of stories from this Sprint including their story point and status information.

Trello ID

Summary Issue Type

Story Points

End of Sprint status / Team

Velocity

#1 As a Bed Manager I want to see current request activity so that I can manage patients beds

Story 3 Complete

#2 As a Bed Manager I want to filter between booking requests by date so that I can see the newest and oldest activity

Story 2 Complete

#3 Create user guide

Story 2 Complete

#4 Update user journey

Story 2 Complete

#5 Add Automated Specflow Tests

3 Complete

#6 Request status icons are the wrong colour

Bug 0 Complete

#7 Add unit tests

Bug 2 Complete

Total 14 14

All stories were implemented and tested, meaning the team’s velocity increased to 14. The sprint latest for 10 developer days without interruption and so 1.4 points worth of tasks were completed per day.

5 Developer Team Resource Profile

The following table shows days recorded by the team:

Name Days Worked on Sprint

Joe Houghton, JH 10

Total 10

83

6 Impediments

Blockers: There are no blockers to report.

The following impediments were noted in the Sprint:

Impediment Improvement Identified to resolve Status

The product owner was absent throughout the sprint and so communication was not always possible.

More contribution is required by the product owner, to write acceptance criteria and regression test the system, so more time can be allocated for developers to write automated tests.

Closed

7 Retrospectives

84

Start

Clarifying requirements prior to development

Considering external testers if product owner continues to be absent Stop

Moving items on the Kanban board back into To Do Keep

Estimating sprint review items

Frequent and smaller commits to Github

Revisiting regression test scripts and acceptance criteria More of

Time spent with product owner

Critical analysis of own code. Discuss trade-off between testing and functionality. Less of

Juggling multiple tasks at once

Interruptions in the developer day. Future work should be planned around other university modules more effectively.

85

9.3.4 Appendix C4: Risk Assessment

86

9.3.5 Appendix C5: Consent Form

Consent form

I understand that the information I provide will be published as a part of a report and I will be sent a copy.

Confidentiality and anonymity will be maintained and it will not be possible to identify me from any publications.

I understand that my participation will be recorded and documents provided will be used as research.

I understand that if I decide at any other time during the research that I no longer wish to participate in this project, I can notify the researcher involved and be withdrawn from the project immediately.

If you agree to participate in my project, please sign and date below.

Thank you,

Joe Houghton

Signed: Margaret Houghton

Date: 23/10/2015

87

9.3.6 Appendix C6: Communication Schedule

88

89

9.3.7 Appendix C7: Document History and Version Control

90

91

9.3.8 Appendix C8: Revision Numbering System

92

9.3.9 Appendix C9: Google Keep

93

9.3.10 Appendix C10: Gantt Chart

94

9.3.11 Appendix C11: Harvest Time Tracking

95

96

9.3.12 Appendix C12: Project Supervisor Meeting Minutes

Project Supervisor Meeting Minutes Date Reviewed: 11/11/2015

Meeting Number: 1

Attendees: Joe Houghton, JH Paul Doney, PD

Date / Time Meeting: 09/11/2015, 11am

Actions agreed at previous meeting Status

Initial Meeting

Comments of student:

1 JH asked if changes should be made to the project plan throughout planning, implementation and evaluation.

2 JH outlined his intentions to make a multi-page MVC application and a single-page application as proof of concept.

3 JH explained that each of the prototypes would be timeboxed to 10 developer working days, in order to calculate his velocity to be used in sprint planning for the production product.

Next meeting: 16/11/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to meet with Product Owner and outline a list of user stories for the prototype product.

2 JH to set up Kanban boards to visualise progress made for the following meetings.

Comments of supervisor (if any):

1 PD commented that good progress was made on the project plan.

97

Project Supervisor Meeting Minutes Date Reviewed: 17/11/2015

Meeting Number: 2

Attendees: Joe Houghton, JH Paul Doney, PD

Date / Time Meeting: 16/11/2015, 11am

Actions agreed at previous meeting Status

1 JH to meet with Product Owner and outline a list of user stories for the prototype product.

Complete

2 JH to set up Kanban boards to visualise progress made for the following meetings.

Complete

Comments of student:

1 JH explained the difficulty of getting form validation to work, as jQuery unobtrusive validation that ships with .NET MVC applications was conflicting with the desired bootstrap framework.

2 JH informed PD that layouts can be reused in .NET MVC applications and this was achieved using partial views.

Next meeting: 14/12/2015 / 11am Agreed Actions to complete before next meeting:

1 JH to start the second proof of concept, a single-page application.

Comments of supervisor (if any):

1 None

98

Project Supervisor Meeting Minutes Date Reviewed: 15/12/2015

Meeting Number: 3

Attendees: Joe Houghton, JH Paul Doney, PD

Date / Time Meeting: 14/12/2015, 11am

Actions agreed at previous meeting Status

1 JH to start the second proof of concept, a single-page application. Complete

Comments of student:

1 JH demoed the progress made on the single-page application. JH made requests to the authorization server to show that it was authenticating the user’s credentials and returning an access token. JH showed that further requests could be made to receive refresh tokens.

2 JH explained that Autofac, an inversion control container was setup to inject dependencies.

3 JH explained that development was still ongoing. At this stage, the AspNetUser Id had not been passed into the claims of the access token and so the front-end of the application had not been implemented.

4 JH commented that he was half way through the sprint and at this stage there were no blockers.

Next meeting: 01/02/2016 / 2.30pm Agreed Actions to complete before next meeting:

1 JH to meet with Product Owner and produce a requirements specification.

Comments of supervisor (if any):

1 PD would like JH to think about the requirements specification for the production product.

2 PD told JH to consider the use of design tools to model the production product.

99

Project Supervisor Meeting Minutes Date Reviewed: 03/02/2016

Meeting Number: 4

Attendees: Joe Houghton, JH Paul Doney, PD

Date / Time Meeting: 01/02/2016, 2.30pm

Actions agreed at previous meeting Status

1 JH to meet with Product Owner and produce a requirements specification.

Complete

Comments of student:

1 JH commented that the product owner had been absent through previous sprints and so he was left responsible to write acceptance criteria and regression test scripts. JH outlined that this was having an impact on time spent developing. This work was estimated into development tasks, but meant the functionality of the product was hindered.

2 JH showed the design tools that had been used in previous sprints.

3 JH commented that mock-up designs had been made and feedback from the product owner was obtained, although the product owner was less concerned about the appearance or usability of the UI and that the main priority was for the MVP stories to be completed.

Next meeting: 05/02/2016 / 2.30pm Agreed Actions to complete before next meeting:

1 JH to create a slideshow and prepare for the work in progress demonstration.

Comments of supervisor (if any):

1 PD informed JH there would be a work in progress demonstration of the project on 17/02/2016 at 1pm. This demonstration would be 10 minutes long, however the final presentation will last 20 minutes.

2 PD told JH to consider using a slideshow to present documentation.

3 PD outlined he would like to hear about the subject of the project, any research related to the project and the findings from the research. The overall approach taken to manage the project. How requirements identified and captured. Design methods that have been applied.

100

Project Supervisor Meeting Minutes Date Reviewed: 03/02/2016

Meeting Number: 5

Attendees: Joe Houghton, JH Paul Doney, PD

Date / Time Meeting: 05/02/2016, 2.30pm

Actions agreed at previous meeting Status 1 JH to create a slideshow and prepare for the work in progress

demonstration.

Complete

Comments of student:

1 JH showed PD the updated regression test script containing acceptance criteria.

2 JH showed PD the production-product-sprint-3-3 Kanban board.

Next meeting: Further communication will be through email Agreed Actions to complete:

1 JH start writing the research section of the final report.

2 PD to check if large excel spreadsheets can be referenced in the appendix.

Comments of supervisor (if any):

1 JH making good progress and is on track.

2 JH should consider writing 500 words per day on the final report, or choosing a blocked period of time to complete it.

3 JH should determine how the final product will be evaluated.

101

Project Supervisor Meeting Minutes Date Reviewed:03/03/2016

Meeting Number: 6

Attendees:

Joe Houghton, JH Paul Doney, PD

Date / Time Meeting:

29/02/2016, 2.30pm

Actions agreed at previous meeting Status 1 JH start writing the research section of the final report. Complete

2 PD to check if large excel spreadsheets can be referenced in the

appendix.

Complete

Comments of student:

1 JH will revisit his presentation to make it more focused on the product, rather than

project planning and methodology.

Next meeting: Further communication will be through email Agreed Actions to complete: 1 Complete the evaluation report by 24/04/2016.

2 Update presentation to focus on the product rather than planning and

methodology.

Comments of supervisor (if any):

1 Work can be hosted on drop box and links to each file can be added to the

appendix.

102

9.3.13 Appendix C13: Starfish Exercise Diagrams

103

9.4 Appendix D

9.4.1 Appendix D1: Regression Test Script

104

105

106

107

108

109

9.4.2 Appendix D2: Definition of Done

Definition of Done

In order for a story to be marked complete, it must meet the following conditions:

Pass code review by JH

Be accessible on the production server

Pass unit and integration testing

Acceptance tested (by PO, JH or Automated were possible)

UI design approved by PO

110

9.4.3 Appendix D3: Story Point Estimation

User Story Estimation Points Date Reviewed: 29/01/2016

This document includes a set of user stories for prototype product 1, prototype product 2 and production product with story point estimation.

1 Prototype Product 1

Story point complexity This table shows the complexity key for the estimation of story points per use case.

Complexity (per use case)

Value 1 2 3 4 5

Rating Easy Simple Medium Complex Very complex

Days 0.25 0.75 1 2 4

Completed tasks to date This is a list of tasks that have been completed to date.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW)

Estimation (Story points)

As a Bed Manager I want to login so that I can manage my beds

M 5

As a Bed Manager I want to see the details of my organisation so that I can check it is correct

M 3

As a Bed Manager I want to update my personal details so that I can keep them up to date

S 3

111

Work in progress tasks

This is a list of the tasks that are to be completed by the deadline of the date 30/11/2015.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW)

Estimation (Story points)

All tasks complete

2 Prototype Product 2

Story point complexity This table shows the complexity key for the estimation of story points per use case.

Complexity (per use case)

Value 1 2 3 4 5

Rating Easy Simple Medium Complex Very complex

Days 0.25 0.75 1 2 4

Completed tasks to date This is a list of tasks that have been completed to date.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW) Estimation (Story points)

As a Bed Manager I want to login so that I can manage my beds

M 5

As a Bed Manager I want to see the details of my organisation so that I can check it is correct

M 2

As a Bed Manager I want to update my personal details so that I can keep them up to date

S 3

Work in progress tasks This is a list of the tasks that are to be completed by the deadline of the date 30/11/2015.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW) Estimation (Story points)

All tasks complete

112

3 Production Product

Story point complexity This table shows the complexity key for the estimation of story points per use case.

Complexity (per use case)

Value 1 2 3 4 5

Rating Easy Simple Medium Complex Very complex

Days 0.25 0.75 1 2 4

Completed tasks to date This is a list of tasks that have been completed to date.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW)

Estimation (Story points)

As a Bed Manager I want to login so that I can manage my beds

M 5

As a Bed Manager I want to see the details of my organisations so that I can check it is correct

M 3

As a Bed Manager I want to update my personal details so that I can keep them up to date

S 3

As a Bed Manager I want to enter the postcode or address of the patients GP so that the area of the practice is displayed on the map and the GP location is marked

M 3

As a Bed Manager I want to enter the patients age and select their gender to search for suitable beds available that match the requirements are marked on the map

M 5

As a Bed Manager I want to see all wards and beds within a specified mile radius so that I can find a bed within suitable range

M 2

As a Bed Manager I want to search with specific bed constraints so that I can find the most appropriate beds available

M 3

As a Bed Manager I want to view search results closest to the GP location on the map including the distance from the GP and bed price

M 3

113

so that I can request a suitable bed

As a Bed Manager I want to make a booking request for a bed, so that I no longer have to make a telephone call to other bed managers

M 3

As a Bed Manager I want to see current request activity so that I can manage patients beds

M 3

As a Bed Manager I want to filter between booking requests by date so that I can see the newest and oldest activity

S 2

Work in progress tasks This is a list of the user stories for the production product. Those prioritized as ‘Must Have’, are considered to be the Minimum Viable Product to be implemented by the deadline 29/01/2016.

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Story Priority (MoSCoW)

Estimation (Story points)

As a Bed Manager I want to turn email alerts on and off so that I can receive alerts when I have a message

C 0.5

As a Bed Manager I want to add and remove specialist bed types so that I can advertise our availability

C 4

As a Bed Manager I want to enable and disable beds so that I can advertise the beds I have on my ward

C 3

As a Bed Manager I want to set costs for beds so that I can sell beds to other trusts

C 1

As a Bed Manager I want to undo my changes when I modify a bed so that I can return to the previous state of setup

C 4

As a Bed Manager I want to edit the specialist bed types so that I can keep bed types up to date

C 3

As a Bed Manager I want to receive an alert so that I am reminded to update our availability

C 3

As a Bed Manager I want to change the number of internal and external beds so that I can advertise bed availability

C 2

As a Bed Manager I want to search for a ward so that I can see all the beds listed

C 3

As a Bed Manager I want to see how many reservations have been made for a bed so that I can respond to requests

C 3

As a Bed Manager I want to add a ward by specifying its name and bed types so that I can add it to a location

W -

As a Bed Manager I want to delete a ward so that it is

removed from a hospital

W -

As a Bed Manager I want to edit a ward so that I can

correct any mistyped information

W -

As a Bed Manager I want to receive an alert when C 3

114

incoming requests are received so that I'm made aware

that someone has requested a bed

As a Bed Manager I want to receive alerts for booking

updates so that I can be informed about current bed

activity

C 3

As a Bed Manager I want to view and reserve a booking

request so that I can review notes before committing to

the request

C 3

As a Bed Manager I want to view and reject a booking

request so that I can cancel a booking request

C 2

As a Bed Manager I want to view and accept a booking

request so that the booking can go forward

C 1

As a Bed Manager I want to receive alerts when a

booking status changes so that I can keep up to date

with my bed requests

C 3

115

9.4.4 Appendix D4: Requirements List

Requirements List

Date Reviewed: 03/11/2015

This document contains an updated list of software requirements for the production product, drawn from the second meeting with the product owner on 02/11/2015. Each requirement has been prioritised, and at this stage it is believed that those marked as must-have must be completed for the project to be successful.

Document Status: Complete – finalized by Product Owner after proof of concept applications

MoSCoW Prioritization Levels: M – Must have, S – Should have, C – Could have, W – Won’t have

Number Type Who Description MoSCow Priority Rating

1 Account Bed Manager

Police

Register W

2 Account Bed Manager

Police

Login and authenticate M

3 Account Bed Manager See details of their organisation

M

4 Account Bed Manager Bed Managers can update their personal details

S

5 Account Bed Manager Turn email alerts on and off C

6 Account Bed Manager Turn SMS alerts on and off W

7 Account Bed Manager Add or remove specialist bed types

C

8 Account Bed Manager Enable and disable their listed beds

C

9 Account Bed Manager Undo change of organisation detail, to return to the previous

state of setup

C

10 Location Bed Manager See all wards and beds within a specified mile radius.

M

11 Booking Bed Manager Receive an alert when an incoming request is made.

C

12 Account Bed Manager Change the number of internal and external beds listed

C

13 Booking Requests

Bed Manager Search for a ward C

14 Booking Requests

Bed Manager See how many reservations have been made for a ward

C

116

15 Account Bed Manager Add a ward by specifying its name, choosing a bed type

and specifying a main point of contact

C

16 Account Bed Manager Delete a ward C

17 Account Bed Manager Edit a ward C

18 Account Bed Manager Enter the postcode or address of the patients GP

M

19 Search Bed Manager Enter the patients age and select their gender to search

for suitable beds

M

20 Search Bed Manager Search with specific bed constraints

M

21 Search Bed Manager Select to allow younger patients to stay with older

patients

W

22 Search Bed Manager View search results closest to the GP location on the map

including the distance from the GP and bed price

M

23 Booking Request

Bed Manager Make a booking request for a bed

M

24 Booking Requests

Bed Manager Receive an SMS alert when incoming requests are

received

W

25 Booking Requests

Bed Manager Receive an email when incoming requests are

received

C

26 Booking Requests

Bed Manager See booking request activity M

27 Booking Requests

Bed Manager Filter between booking requests by date

S

28 Booking Requests

Bed Manager Receive alerts for booking updates

C

29 Booking Requests

Bed Manager View and confirm a booking request

C

30 Booking Requests

Bed Manager View and reject a booking request

C

31 Booking Requests

Bed Manager View and accept a booking request

C

32 Booking Requests

Bed Manager Receive alerts when a booking status changes

C

117

9.4.5 Appendix D5: Skills Audit

118

9.5 Appendix E

9.5.1 Appendix E1: Project Plan

Below is the finalized project plan, which was refined throughout the project up until a minimum viable product was agreed on with the product owner. Assumptions made previous to sprint planning sessions have been updated and tasks out of scope have been marked.

PROJECT PLAN (REVISITED AFTER INITIAL SUBMISSION) Name: Joe Houghton

Student I.D.: C3375905

Course: BSc (Hons) Computing

Supervisor’s Name: Paul Doney

Title of the Project: Production Project

Aim of the Final Project: To explore and evaluate traditional multi-page and modern single-page application architectural patterns, in order to design and implement a web application, that aims to tackle the current crisis faced by the NHS of finding local patient bed availability.

Objectives of the Final Project:

Review and gather material on the project topic

Initial research into the NHS to understand the current crisis they are facing of finding bed availability for patients, to build knowledge and guide the research stage. Research will be drawn from multiple sources such as videos, web pages and published reports.

Utilise an Agile Methodology to manage the entire project

Although the Gantt Chart suggests this project will use the traditional waterfall approach, Agile methods should be used to plan and self-organise. Kanban boards should be created for all sprint development, and documents to record story point estimation, end of sprint reports, acceptance criteria and regression tests.

Research and identify the different architectural patterns used for web applications

The web application to be designed and developed will support multiple pages and views. It is important to gain awareness of the current architectural patterns used, before further investigation can be carried out, by creating prototype applications.

Research web application authentication and security

The product will be used by different end users, who will have access to specific information or possibly perform different actions based on their role. Understanding the different approaches to authenticate and their levels of security to ensure the protection of data is vital.

Examine current business processes and users involved

It is necessary to gain a broader understanding of the current problems faced in the NHS around finding bed availability for patients, to determine product functionality. This will be through self-research and interviews with the product owner. Having gained an understanding, a requirements list will be produced and signed off by the client.

Document minimum viable product for prototype application

119

A meeting will be held with the client to look at the requirements list and break down any epics into a list of user stories. Stories will be added to the backlog of the Kanban board. An estimation scale will be agreed and the smallest and largest possible story will be defined. Each story will be estimated using the agile Planning Poker technique. Stories which are required to be implemented in order to meet the expectations of a minimum viable prototype product will be documented.

Create two prototype product applications

Using the initial research, two prototype products will be developed as proof of concept. Each prototype will be written using a different architectural pattern. The prototype products will aim to meet the stories defined as minimum viable product. Thoughts and findings throughout will be documented, to help form the literate review.

Make final product recommendations and specify the approach to be taken

A literature review on web application architectural patterns will be written using the research gathered. A recommendation will be made and the approach to develop the final product will be outlined, based on the findings from the prototype products.

Review and update project planning documentation

Having completed the research stage, initial planning documentation will be reviewed and any new requirements will be added.

Outline a definition of done for user stories

It is important to establish a list of activities that are required before a story can be marked as done or sprint to be classed as complete. Each story should have automated tests, unit tests or user acceptance tests were possible. Regression test scripts must be written tested for each story. The complexity of the definition of done will be considered in sprint planning and have an impact on the amount of functionality delivered overall.

Create a backlog of user stories for the minimum viable product

Meetings will be held with the client to look at the requirements list and break down any epics into a list of user stories. Stories will be added to the backlog of the Kanban board. By reflecting on previous prototype product sprints, the user story estimation scale will be redefined by assigning points to the smallest and largest story of the prototype product. Each story will be estimated using the agile Planning Poker technique. Stories which are required to be implemented in order to meet the expectations of a final minimum viable product will be documented.

Design the final product

Design the front-end by creating a set of wireframes for the minimum viable product. These wireframes will provide a visual representation of how the user interface will look. It is important to get feedback from the client. To design the back-end, UML Class and Use Case diagrams will be produced, to steer the focus of the technical implementation. These will be updated throughout the sprints.

Configure the environment to host and manage the product

Research cloud and self-hosting to find the most suitable and cost effective way to host the product. Configure the server and database. Register domain names. Setup Git repositories for version control.

Develop and implement the final product

Taking an agile approach, the aim is to develop the final product in 3 sprints over a period of 6 weeks. A sprint planning session will be carried out at the beginning of each sprint with the product owner. In these meetings progress will be demonstrated,

120

reflection will be made on previous sprints new requirements will be defined based on feedback. With input from the product owner, the developer’s velocity from the previous sprint will be calculated to determine how much development can be completed in the next sprint. With the velocity in mind, stories from the backlog will be prioritised and added to the Kanban board. Any uncompleted tasks or bugs raised will roll over into the next sprint and reprioritised.

Reflect on the project

Evaluate the project as a whole, from the planning stage through to delivery and critically evaluate the final product to determine whether the project objectives were met. Reflect on performance throughout the project and analyse the effectiveness of project management techniques used.

121

Specification of the Final Product: Introduction The NHS currently face the crisis of finding patient bed availability. As a result, patients are left without adequate care and are admitted to facilities miles from their homes, relatives and support systems (Corbyn, 2015). This project aims to tackle the problem, by designing and implementing an online service for sharing bed availability across the NHS and with private care providers. This system enhances patient care, by allowing beds to be found closer to the patient’s home. Impact Analysis

Increased cost savings across the NHS

The service will promote value for money. The NHS face the problem of low level of bed availability, which results in high administration and ongoing care costs with private organisations. In 2013, a mental health trust spent £350,000 allocating patients to private bed and breakfast accommodation (Buchanan, 2014). The service will group bed availability by constraints and present a list of bed costs to the end user. It will allow bed managers to book the cheapest bed available, and encourage providers to list their beds at a similar and reasonable asking price.

Reduces the manual administration process of booking patient beds

Bed Managers will no longer have to manually fill out booking request forms and fax them through to other organisations or external providers. This speeds up the booking process and reduces paperwork.

Functional Requirements

Unauthenticated users must not be able to use the service

1. Any attempt to use the service without authentication will redirect the user to the login page and prompt the user to login.

A registration form will be present on the landing page, allowing private providers to sign up to the system. An assumption has been made that NHS bed providers and police do not need to register, and can authenticate with their work email addresses (see next requirement). Once the registration has been approved, the user will be stored in the database with bed manager privileges to manage their own organisation. [Update: Not part of MVP]

1. User must specify their organisation type. This organisation type will have predefined bed types associated with it. For example, organisations with Gynaecology wards will offer female only beds.

2. Username must be a minimum of 6 characters.

3. Password must be a minimum of 6 characters, contain a minimum of 1 uppercase letter and a minimum of 1 non-alphanumeric character.

4. User must specify their organisation postcode, with a maximum length of 9 characters. A POST request will be made to Googles geocoding API including the postcode, and if valid a response will return a JSON encoded latitude and longitude. This latitude and longitude will be stored in the database.

A login form will be present on the landing page of the website allowing registered users with different roles to login and authenticate securely by entering their email address or username, followed by their password. The form will make a request to the back-end authentication server with the

122

user’s credentials. The authentication server will generate a Jason Web Token and return it to the client. This token will be used for subsequent requests. Token-based authentication is preferable over cookie authentication which are prone to XSRF attacks (Tkalec, n.d.).

1. Bed Managers can authenticate with their NHSmail email address (.nhs.net domain). [Update: Not part of MVP]

2. Police users can authenticate with their police email address (.pnn.police domain).

[Update: Not part of MVP]

3. External providers can login with their registered email address. [Update: Not part of MVP]

4. All users can alternatively login with their registered username. [Update: Not part of MVP]

A manage page will allow users to manage their organisations bed availability for each ward

1. Internal availability for each ward can be changed by user input. Internal availability is private to the organisation.

2. External availability for each ward can be changed via user input. External availability is visible to other organisations using the system.

3. Availability fields are restricted to numeric input.

Bed types are non-configurable

1. An assumption has been made that specialists offer the same bed types, and therefore pre-defined beds are set when the organisation type is specified.

NHS and private organisations can view their organisation detail

1. A page will display the organisation name and type.

2. These fields are read-only, to prevent users from viewing other organisations data.

3. Police users must not be able to view detail of any organisation, and can only use the service to search for a bed. [Update: Not part of MVP]

NHS and private organisations can view and edit their personal detail. Their contact details are added to the booking detail when a request is made.

1. The following fields are displayed: full name, email, telephone and mobile.

2. Unlike bed managers from private organisations, NHS users cannot edit their email address. [Update: All users can edit their email address]

3. Bed managers can enable and disable email and SMS alerts. By opting in, they will receive updates for incoming and outgoing booking requests. [Update: Not part of MVP]

All users can search for a bed by entering care requirements

1. The initial search view will display a 2D Google Map in Map view. The default map position will be the geolocation of the users organisation, or Leeds Beckett University Headingley Campus for

123

police users. This position will be marked on the map with a home icon.

2. The GP closest to the organisation will be marked on the map with a GP icon.

3. The user can enter the following constraints: age (0-100, any), gender (male, female, both), tier (low, medium, high, all), postcode of patients GP, distance of search results (upto 300 miles). [Update: 15, 25, 50 100, 300 miles]

The top five results closest to the patients GP will be displayed on the map

[Update: The top four results]

1. A request will be made to Googles geocoding API sending the postcode, and if valid a response will return a JSON encoded latitude and longitude. This postcode will be displayed on the map with a GP icon.

2. If no results are found the user will prompted to re-enter the postcode

3. A request will be made to the back-end, sending the search constraints, longitude and latitude. If beds are found, a maximum of five results will be returned. Each bed will be marked on the map with a bed icon, using its longitude and latitude found in the JSON encoded response.

4. If no results are returned from the back-end, the user will be prompted to change their requirements

5. There will be an overlay on the map displaying the search form from the previous screen, populated with the search criterion, allowing the user to make amendments. Each bed type will be listed, and include detail of its name, age, gender, tier, price (to two decimal places) and mileage from GP (to two decimal places).

6. Selecting a bed marker will highlight the bed result in the list.

7. Each bed result item will have a hyperlink labelled “Make Booking”, containing a data attribute with a value set to the bed id. This link will only be displayed for bed manager users. When clicked, the user is taken to a page displaying booking information for the selected bed, by making a HTTP request or setting a URL parameter.

A booking request can be made for the selected bed

1. Having selected a bed, the user is presented with the following attributes associated with the bed: organisation name, organisation type, age, gender, tier, and price (to two decimal places).

2. A ten digit patient identifier can be entered which will be used by the receiving end to process the booking.

3. Non-Clinical notes (text) can be entered as part of the booking request.

4. Email addresses for NHS organisations listing beds will be provided, so clinical information can be sent to via NHSmail, a separate service, if necessary.

5. The booking request details will be stored in the database, along with a booking status, date and time of booking.

6. Clicking the hyperlink labelled “Return to Results” navigates the user back to the search results page.

124

7. A fire and forget email will be sent to users in the receiving organisation who have opted for email alerts.

8. An SMS message will be sent to users in the receiving organisation who have opted for SMS alerts.

9. The user is redirected to see their current list of bookings.

Incoming and outgoing booking requests can be monitored

1. Bed managers can view a list of all outgoing and incoming requests. Each request should include the following detail: Patient Identifier, Status (Requested, Rejected), Type (Incoming, Outgoing), Organisation From, Organisation To, Tier, Date and Time. The date and time will be follow the format “14-Dec-2015” and formatting will be done on the client-side.

2. Booking requests will be sorted by date and time. By default will be sorted in descending order.

3. Booking requests will be filtered by incoming and outgoing types.

Non-Functional Requirements

Database changes must be monitored and consistent across local and production environments

1. Database schema changes will be documented, in the form of UML Class diagram.

2. Scheduled database backups will run on a nightly basis using SQL Agent Jobs, a service in SQL Server 2014 Management Studio that executes scheduled tasks (Microsoft, n.d.).

[Update: Not part of MVP]

3. In order to ensure the latest database changes have been made on local and remote environments, DbUp will be added to the project, which will keep track and run and change scripts that haven’t already been executed (DbUp n.d.).

Prototype and production products accessible via public URL at:

http://proof-of-concept-spa.houghtonjoe.com/

http://proof-of-concept-mvc.houghtonjoe.com/

http://production-project.houghtonjoe.com/

All queries will be executed and pages will be loaded within 3 seconds, as a study conducted by Zona Research indicated that 40% of users will abandon a website if response times exceed this time (Godskind, 2009).

The final product will be hosted with 24/7 service [Update: Redundancy measures would be an essential requirement for an industry based product, but it is not feasible as this project will not be funded.]

1. A server farm will be configured for load balancing. Distributing requests amongst servers will reduce the chances of servers falling over from high network traffic (Microsoft, n.d.).

2. UPS devices will be used, to keep servers running if the main source

125

of power is lost (Rouse, n.d.).

3. Two drives will be setup in RAID 1 for local and production environments. Having the drives mirror each other helps prevent data loss, if one drive becomes corrupt (Microsoft, n.d.).

4. The server will be locked away in a non-public area, only accessible via Remote Desktop Connection.

Source code for all sprints must be backed up 1. Code will be hosted in a secure GitHub repository. 2. Repositories will be set to private and accessible upon request.

Code standards will be met throughout all development 1. StyleCop will be used to analyse C# server-side code and enforce

coding standards (StyleCop, n.d.). [Update: Not part of MVP] 2. JSHint will be used to identify problems in client-side JavaScript code

(JSHint, n.d.).

Clinical Information is not held in the system 1. The service will not require clinical information to function. Bed

Managers will be prompted to send patient data via NHSMail.

The server side code will run using the current .NET Framework version 4.5

Code will enhance scalability 1. Code will be loosely coupled and follow Inversion of Control

principles. A dependency injector such as Ninject or AutoFac will be used, to inject dependencies into class constructors. By applying this design pattern, dependencies such as database connections can be swapped out easily should the application grew larger and class reuse is enhanced (Ninject, n.d.). [Update: Autofac will be used for dependency injection]

Code is tested to a high standard 1. Unit tests will cover 70% of code. This proportion will be estimated

with Code Coverage, a tool provided by Microsoft. 2. Automated web browser regression tests will be written and ran

using Selenium.

The website will support the following devices and browsers: Device Testing

Product Desktop

(1200 x 800)

Tablet

iPad Retina – iOS 7

(1024 x 768 min)

Mobile

iPhone 4S –IOs 7

iPhone 5S –IOs 7

(320 x 480 min)

TV

1080P

(1920 x 1080)

Prototype Yes

Yes Yes Yes

Production Product

Yes Yes No No

Browser Testing

Browser IE Firefox Chrome Safari

Version Current -11 Current -2 Current -2 Current -10

126

References

Buchanan, M. (2014) Mental health patients forced to travel miles for care [Online]. Available from: <http://www.bbc.co.uk/news/uk-27285555/> [Accessed 22nd October 2015].

Channel 4 News (2015) Jeremy Corbyn vs David Cameron – watch PMQs live [Online video], 16 September. Available from:<http://www.youtube.com/watch?v=3-0KkGdPIz4>[Accessed 22 October 2015].

DbUp (n.d.) DbUp [Online]. Available from:<https://dbup.github.io/>[Accessed 20th May 2012].

Godskind, K. (2009) 5, 10, 15 seconds? How Long Will You Wait For a Web Page to Load?. Smart Bear, 14 October [Online blog]. Available from:<http://blog.smartbear.com/software-quality/5-10-15-seconds-how-long-will-you-wait-for-a-web-page-to-load/>[Accessed 22 October 2015].

Google (2015) The Google Maps Geocoding API [Online]. Available from:<http://developers.google.com/maps/documentation/geocoding/intro>[Accessed 22nd October 2015].

HSCIC (n.d.) Sending secure email [Online]. Available from:<http://systems.hscic.gov.uk/nhsmail/secure>[Accessed 22nd October 2015].

JSHint (n.d.) JSHint, A Static Code Analysis Tool for JavaScript [Online]. Available from:<http://jshint.com/about/>[Accessed 20th May 2012].

Microsoft (n.d.) About Server Farms [Online]. Available from:<https://technet.microsoft.com/en-gb/library/cc995240.aspx>[Accessed 22nd October 2015].

Microsoft (n.d.) Overview of Redundant Arrays of Inexpensive Disks (RAID) [Online]. Available from:<https://support.microsoft.com/en-us/kb/100110>[Accessed 20th May 2012].

Microsoft (n.d.) SQL Server Agent [Online]. Available from:<http://msdn.microsoft.com/en-us/library/ms189237.aspx>[Accessed 22nd October 2015].

Ninject (n.d.) Ninject! Open source dependency injector for .NET [Online]. Available from:<http://www.ninject.org/>[Accessed 20th May 2012].

Rouse, M. (n.d.) uninterruptible power supply [Online]. Available from:<http://searchdatacenter.techtarget.com/definition/uninterruptible-power-supply>[Accessed 22nd October 2015].

127

StyleCop (n.d.) StyleCop [Online]. Available from:<https://stylecop.codeplex.com/>[Accessed 20th May 2012].

Tkalec, T. (n.d.) JSON Web Token Tutorial: An Example in Laravel and AngularJS [Online]. Available from:<http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs>[Accessed 22nd October 2015].

128

PROJECT PLANNING DOCUMENTS

Project Schedule – Gantt Chart

Document History and Version Control

Skills Audit

Communication Schedule

Risk Assessment

Kanban board - Prototype Product 1: <https://trello.com/b/M8qeM19X>

Kanban board - Prototype Product 2: <https://trello.com/b/zSknqBb2>

Kanban board - Production Product : <https://trello.com/b/GQkRElzh>

Wireframes

Estimation

End of Sprint Report Template

Regression Test Script

129

PHYSICAL RESOURCE The hardware and software I require to complete my Project successfully:

Item Type

Supplier Source Quantity Cost

Laptop Hardware Own Own 1 £0.00

Server Hardware Own Own 1 £0.00

Windows Server

2012

Software Dream Spark <https://www.dreamspark.com/> 1 £0.00

Microsoft SQL

Server 2014

Management Studio

Software Dream Spark <https://www.dreamspark.com/> 1 £0.00

Resharper (visual

studio extension for

.NET)

Software Jet Brains <https://www.jetbrains.com/student/> 1 £0.00

Github account with

private repositories

Software GitHub <https://education.github.com/pack> 3 £0.00

Trello Kanban board Software Trello <https://trello.com/> 3 £0.00

Visual Studio

Community 2015

Software Dream Spark <https://www.dreamspark.com/> 1 £0.00

Ruby for Sass CSS Software Ruby <https://www.ruby-lang.org/> 1 £0.00

130

HUMAN RESOURCE I am working on my Project with the following people

Name

Organisation Role Responsibility

Paul Doney

Leeds Beckett University Staff Supervisor Provide feedback every two

weeks throughout the

project.

Margaret Houghton

National Health Service

Client / Product Owner Provide an insight of the

current business flow and

address issues.

Have a vision of the final

product and convey that

vision for it to be

developed.

Provide feedback on

developer work at sprint

retrospectives.

Attend meetings and sprint

planning sessions.

131

INITIAL BIBLIOGRAPHY Bin, H. (2014) Study on MVC-based Teaching System Design in Engineering Colleges.

Applied Mechanics & Materials, 519 (1), pp. 1622-1625.

Buchanan, M. (2014) Mental health patients forced to travel miles for care [Online].

Available from: <http://www.bbc.co.uk/news/uk-27285555/> [Accessed 22 October

2015].

Channel 4 News (2015) Jeremy Corbyn vs David Cameron – watch PMQs live

[Online video], 16 September. Available from:<http://www.youtube.com/watch?v=3-

0KkGdPIz4>[Accessed 22 October 2015].

Dacosta, I. (2012) One-Time Cookies: Preventing Session Hijacking Attacks with

Stateless Authentication Tokens. ACM TRANSACTIONS ON INTERNET TECHNOLOGY,

61 (1) May, pp. 124-144.

Iqbal, H. and Apu, S (2014) MVC Architecture Driven Design and Implementation of Java

Framework for Developing Desktop Application. International Journal of Hybrid

Information Technology, 7 (5) September, pp. 317-322.

Jacobson, I. (2013) Agile and SEMAT- Perfect Partners. Communications of the ACM,

56 (11) November, pp. 53-59.

Liu, Alex. (2012) A secure cookie scheme. Computer Networks, 56 (6) April, pp. 1723-

1730.

Mesbah, A. and Deursen, A. (2006) Migrating Multi-page Web Applications to Single-page Ajax Interfaces. 2nd ed. The Netherlands: Software Engineering Research Group.

Pop, D. and Altar, A. (2015) Designing an MVC Model for Rapid Web Application

Development. International Symposium on Intelligent Manufacturing and

Automation, 69 (1), pp. 1172-1179.

Renien, J. (2015) SINGLE PAGE APPLICATION AND CANVAS DRAWING. International

Journal of Web & Semantic Technology, 6 (1) January, pp. 29-36.

Torrecilla-Salinas, C. (2015) Estimating, planning and managing Agile Web development

projects under a value-based perspective. Information and Software Technology, 61

(1) May, pp. 1622-1625.

Torroglosa-Garcia, E. (2013) Integration of the OAuth and Web Service family security

standards. Towards a Science of Cyber Security, 57 (10) July, pp. 2233-2249.

132

9.6 Appendix F

9.6.1 Appendix F1: User Journey

133

134

135

136

9.6.2 Appendix F2: User Guide

A setup guide added to the Git repository:

137

10 Bibliography

Agile Alliance (n.d.) Mock Objects [Online]. Available from: <http://guide.agilealliance.org/guide/mocks.html> [Accessed 22 October 2015]. Ambler (2014) UML 2 Use Case Diagramming Guidelines [Online]. Available from: <http://agilemodeling.com/style/useCaseDiagram.htm> [Accessed 23October 2015]. Atlassian (n.d.) Five agile metrics you won’t hate [Online]. Available from: <https://www.atlassian.com/agile/metrics> [Accessed 22 October 2015]. Atlassian (n.d.) Why code reviews matter (and actually save time!) [Online]. Available from: <https://www.atlassian.com/agile/code-reviews> [Accessed 24 October 2015]. Automapper (n.d.) What is Automapper? [Online]. Available from: <http://automapper.org/> [Accessed 22 October 2015]. Backbonejs (n.d.) Backbone.history [Online]. Available from: <http://backbonejs.org/#History/> [Accessed 08 October 2015]. Bailey, D (2012) Why Should I Use Backbone.Marionette Instead Of … ? [Online]. Available from: <https://lostechies.com/derickbailey/2012/06/13/why-should-i-use-backbone-marionette-instead-of-.../> [Accessed 08 October 2015]. Besson, F. and Moura, P. and Kon, F. and Milojicic, D. (2015) Bringing Test-Driven Development to web service choreographies. Journal of Systems and Software, 99 (1) January, pp. 125. Bissi, W. and Neto, A. and Emer, M. (2016) The effects of test driven development on internal quality, external quality and productivity: A systematic review. Information and Software Technology, 74 (1) August, pp. 45. Bower (n.d.) A package manager for the web [Online]. Available from: <http://bower.io/> [Accessed 03 December 2015]. Cagiltay, N. (2013) Performing and analyzing non-formal inspections of entity relationship diagram (ERD). Journal of Systems and Software, 86 (8) August, pp. 2184. Cayenne (2016) 5 STEPS TO BUILDING MINIMUM VIABLE PRODUCT WITH STORY MAPPING. [Online]. Available from: <http://blog.cayenneapps.com/2014/11/25/5-steps-to-building-minimum-viable-product-with-story-mapping/> [Accessed 01 March 2016]. Channel 4 News (2015) Jeremy Corbyn vs David Cameron – watch PMQs live [Online video], 16 September. Available from:<http://www.youtube.com/watch?v=3-0KkGdPIz4>[Accessed 22 October 2015]. Cohn, M. (2014) User Stories Applied. 1st ed. Addison Wesley. Cortez, R. and Vazhenin, A. (2014) Virtual Model-View-Controller Design Pattern: Extended MVC for Service-Oriented Architecture. IEEJ Trans, 10 (1) September, pp. 412-413. Cusumano, Michael A. (2007) Extreme Programming Compared with Microsoft-Style Iterative Development. Communications of the ACM, 50 (10) October, pp. 15-18.

138

DbUp (n.d.) Simple database migrations [Online]. Available from: <https://dbup.github.io/> [Accessed 09 December 2015]. Dolques, X. (2013) Fixing Generalization Defects in UML Use Case Diagrams. Fundamenta Informaticae, 115 (4) February, pp. 329. Entity Framework Tutorial (n.d.) What is Entity Framework? [Online]. Available from: <http://www.entityframeworktutorial.net/what-is-entityframework.aspx> [Accessed 01 December 2015]. Etter, J (2012) Mobile Development with Single-Page Applications Using KendoUI [Online]. Available from: <http://www.codemag.com/article/1308071> [Accessed 01 December 2015]. Git (n.d.) Branching and Merging [Online]. Available from: <https://git-scm.com/about/> [Accessed 04 October 2015]. Gonçalves, L (n.d.) “Starfish exercise” for Agile Retrospectives [Online]. Available from: <http://lmsgoncalves.com/2013/08/07/getting-value-out-of-agile-retrospectives-starfish/> [Accessed 07 January 2016 Google (n.d.) Minify Resources (HTML, CSS, and JavaScript) [Online]. Available from: <https://developers.google.com/speed/docs/insights/MinifyResources#overview> [Accessed 01 January 2016]. Gupta, R (n.d.) 7 Mistakes During the Daily Stand-up Meeting [Online]. Available from: <https://www.scrumalliance.org/community/articles/2014/july/7-mistakes-during-the-daily-stand-up-meeting/> [Accessed 01 January 2016 Gupta, S (n.d.) 9 Principles (building blocks) of DSDM – AGILE [Online]. Available from: <http://www.quotium.com/performance/9-principles-building-blocks-dsdm-agile/> [Accessed 09 December 2015]. Grunt (n.d.) The JavaScript Task Runner [Online]. Available from: <http://gruntjs.com/> [Accessed 01 March 2016]. Harvest (2016) Time tracking your team will actually use. [Online]. Available from: <https://www.getharvest.com/tour/> [Accessed 28 December 2016]. Hudson, T (n.d.) WHAT IS REGRESSION TESTING? [Online]. Available from: <https://smartbear.com/learn/automated-testing/what-is-regression-testing/> [Accessed 01 March 2016]. JSHint (n.d.) JSHint, A Static Code Analysis Tool for JavaScript [Online]. Available from: <http://jshint.com/about/> [Accessed 01 March 2016]. Lakshminarayan, B (2013) An Agile Process for User Acceptance Testing [Online]. Available from: <https://www.scrumalliance.org/community/articles/2013/july/an-agile-process-for-user-acceptance-testing/> [Accessed 01 March 2016]. Lowdermilk, T. (2011) User-centered design. 1st ed. O’Reilly. MarionetteJs (2016) Backbone.radio [Online]. Available from: <https://github.com/marionettejs/backbone.radio> [Accessed 01 November 2015].

139

Mayer, D (2013) Improving Agile Estimation via Triangulation [Online]. Available from: <http://blogs.atlassian.com/2013/01/improving-agile-estimation-with-triangulation/> [Accessed 01 March 2016]. Microsoft (n.d.) Data Transfer Object [Online]. Available from: <https://msdn.microsoft.com/en-us/library/ff649585.aspx> [Accessed 01 November 2015]. Microsoft (n.d.) DbGeography Class [Online]. Available from: <https://msdn.microsoft.com/en-us/library/system.data.spatial.dbgeography(v=vs.110).aspx/> [Accessed 01 March 2016]. Microsoft (n.d.) Effective Sprint Retrospectives [Online]. Available from: <https://msdn.microsoft.com/en-us/library/jj620912(v=vs.120).aspx#bkmk_overview> [Accessed 01 March 2016]. Microsoft (n.d.) How to: Deploy a Web Application Project Using One-Click Publish and Web Deploy [Online]. Available from: <https://msdn.microsoft.com/en-us/library/dd465337(v=vs.100).aspx> [Accessed 01 March 2016]. Microsoft (n.d.) Robocopy [Online]. Available from: <https://technet.microsoft.com/en-GB/library/cc733145.aspx> [Accessed 01 March 2016]. Microsoft (n.d.) The Repository Pattern [Online]. Available from: <https://msdn.microsoft.com/en-us/library/ff649690.aspx> [Accessed 01 November 2015]. Mountain Goat (n.d.) Daily Scrum Meeting [Online]. Available from: <https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum> [Accessed 02 November 2015]. NHS England (n.d.) Health and high quality care for all, now and for future generations [Online]. Available from: <https://www.england.nhs.uk/accessibility/> [Accessed 01 March 2016]. Node Package Manager (n.d.) A stylish JSCS Reporter [Online]. Available from: <https://www.npmjs.com/package/jscs-stylish> [Accessed 01 March 2016]. Papadopoulos, G. (2015) Moving from traditional to agile software development methodologies also on large, distributed projects. Procedia - Social and Behavioral Sciences, 175 (1) September, pp. 456-458. Pătraşcu, A. (2015) Comparative Analysis between OWL Modelling and UML Modelling. Gas University of Ploiesti Bulletin, Technical Series, 64 (2) February, pp. 87. Performance (n.d.) Visual Merge and Diff Tools [Online]. Available from: <https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools> [Accessed 01 March 2016]. Pichler, R (2012) A Template for Writing Great Personas [Online]. Available from: <http://www.romanpichler.com/blog/persona-template-for-agile-product-management/ > [Accessed 01 December 2015]. Pop, D. and Altar, A. (2015) Designing an MVC Model for Rapid Web Application Development. International Symposium on Intelligent Manufacturing and Automation, 69 (1), pp. 1172-1176.

140

Pomar, F. and Calvo-Manzano, J. and Caballero, E. and Arcilla-Cobián, M. (2014) Understanding sprint velocity fluctuations for improved project plans with Scrum: a case study. JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS, 26 (1) August, pp. 776-777. Povilaitis, S (2014) ACCEPTANCE CRITERIA [Online]. Available from: <http://www.leadingagile.com/2014/09/acceptance-criteria/> [Accessed 07 November 2015]. Radigan, D (n.d.) A brief introduction to kanban [Online]. Available from: <https://www.atlassian.com/agile/kanban/> [Accessed 01 March 2016]. Renien, J. (2015) SINGLE PAGE APPLICATION AND CANVAS DRAWING. International Journal of Web & Semantic Technology (IJWesT), 175 (1) January, pp. 29-30. Require (n.d.) REQUIREJS API [Online]. Available from: <http://requirejs.org/docs/api.html> [Accessed 01 November 2015]. Sass (n.d.) CSS with superpowers [Online]. Available from: <http://sass-lang.com/> [Accessed 01 November 2015]. Sabir, F. (2013) A COMPARISON OF MODEL VIEW CONTROLLER AND MODEL VIEW PRESENTER. Sci.Int.(Lahore), 25 (1) September, pp. 7. Smith, S (2009) Don’t Repeat Yourself [Online]. Available from: <http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself> [Accessed 01 March 2016]. Specflow (n.d.) Cucumber for .NET [Online]. Available from: <http://www.specflow.org/documentation/> [Accessed 07 Novemberh 2015]. Sundvall, E. and Nyström, M. and Karlsson, D. and Eneling, M. and Chen, R. and Örman, H. (2013) Applying representational state transfer (REST) architecture to archetype-based electronic health record systems. BMC Medical Informatics and Decision Making, 175 (1) February, pp. 24. Waters, K (2008) User Stories Should Be Testable [Online]. Available from: <http://www.allaboutagile.com/user-stories-should-be-testable/> [Accessed 01 March 2016]. Waters, K (2008) Agile Principle 10: No Place For Snipers! [Online]. Available from: <http://www.allaboutagile.com/agile-principle-10-no-place-for-snipers/> [Accessed 01 March 2016]. Williams, I (2014) Things I Learned from Building a Large Scale Backbone + Marionette Application [Online]. Available from: <http://authenticff.com/journal/building-large-scale-backbone-marionette-applications> [Accessed 08 November 2015]. Zurb (n.d.) Mobile First [Online]. Available from: <http://zurb.com/word/mobile-first/> [Accessed 01 March 2016].