TÝR - R&D Client for Bionic Prosthetics Össur hf. Report... · 2019-08-30 · TÝR - R&D Client for Bionic Prosthetics Össur hf. School of Computer Sci-ence B.Sc. Final Report

TÝR - R&D Client for Bionic ProstheticsÖssur hf.

Benedikt Valur ÁrnasonEgill Anton Hlöðversson

Jón SöringSkúli Þór Jónasson

Final Report in School of Computer ScienceB.Sc.

2017Supervisor Torfi Helgi Leifsson

Examiner Guðný Ragna Jónsdóttir

Teacher Hallgrímur Arnalds

School of Computer ScienceTölvunarfræðideild

Heiti verkefnis:

Námsbraut: Tegund verkefnis:

Önn: Námskeið: Ágrip:

Höfundur:

Umsjónarkennari:

Leiðbeinandi:

Fyrirtæki/stofnun:

Dagsetning: Lykilorð íslensk: Lykilorð ensk:

Dreifing:opin lokuð til:

Háskólinn í Reykjavík Menntavegi 1, 101 Reykjavík sími: 599 6200 www.ru.is

TÝR - R&D Client for Bionic ProstheticsÖssur hf.

School of Computer Sci-ence B.Sc.

Final Report in Computer Science B.Sc.

2017-1 T-404-LOKA

Benedikt Valur ÁrnasonEgill Anton HlöðverssonJón SöringSkúli Þór Jónasson

Hallgrímur Arnalds

Torfi Helgi Leifsson

Össur hf.Grjótháls 1-5110 Reykjavík

11.5.2017 Össur, Stoðtæki,Snjallforrit, Xamarin,Bionics

Ossur, Prostheticdevices, App,Xamarin, Bionics

TÝR not only allows specialists at Össur hf.to quickly check vital information from bionicprosthetic devices but also enables them toeasily adjust the functionality and accessvaluable reports. TÝR is a cross-platformapplication available for Windows 10, Androidand iOS and communicates wirelessly viaWi-Fi. This paper describes the proceduresused to create and develop the softwaresolution TÝR.

TÝR leyfir ekki aðeins sérfræðingum hjáÖssuri hf. að sækja á einfaldan hátt helstuupplýsingar frá stoðtækjum heldur auðveldarþeim einnig að stilla virkni og fá aðgang aðmikilvægum skýrslum um starfsemi tækisins.TÝR er fjölvangs-snjallforrit sem keyrir á Win-dows 10, Android og iOS og hefur þráðlaussamskipti við stoðtæki í gegnum Wi-Fi. Þessiskýrsla lýsir þeim aðferðum sem var beitt viðþróun á hugbúnaðarlausninni TÝR.

X

iii

Contents

Contents iii

List of Figures vi

List of Tables vii

1 Introduction 11.1 About the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 About Össur hf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Methodology 22.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1.1 Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.2 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1.3 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Software & Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Organization 53.1 Reports and Deadlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Expected Project Burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Risk Analysis 94.1 Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Incident Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Design 135.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2 Xamarin.Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2.1 MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3 Back-end Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.3.1 Local Database Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.3 Syncing Data to Bionics Cloud . . . . . . . . . . . . . . . . . . . . . . 17

5.4 Navigation Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.5 Mock-ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.5.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5.2 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.5.3 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iv

5.5.4 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.5.5 Modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Testing 216.1 Back-end Unit Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 System Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.3 User Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3.2 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7 Sprints 247.1 Sprint 0 (January 7th - January 20th) . . . . . . . . . . . . . . . . . . . . . . . 24

7.1.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247.1.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.2 Sprint 1 (January 21st - February 3rd) . . . . . . . . . . . . . . . . . . . . . . . 267.2.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.2.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.2.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.2.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.3 Sprint 2 (February 4th - February 17th) . . . . . . . . . . . . . . . . . . . . . . 287.3.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.3.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.3.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.3.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.4 Sprint 3 (February 18th - March 3rd) . . . . . . . . . . . . . . . . . . . . . . . 307.4.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.5 Sprint 4 (March 4th - March 17th) . . . . . . . . . . . . . . . . . . . . . . . . . 327.5.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.5.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.5.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.5.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.5.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7.6 Sprint 5 (March 18th - March 31st) . . . . . . . . . . . . . . . . . . . . . . . . 347.6.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.6.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.6.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.6.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.6.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.7 Sprint 6 (April 1st - April 14th) . . . . . . . . . . . . . . . . . . . . . . . . . . 367.7.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

v

7.7.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.7.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.7.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.7.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.8 Sprint 7 (April 15th - April 28th) . . . . . . . . . . . . . . . . . . . . . . . . . 387.8.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.8.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.8.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.8.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.8.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.9 Sprint 8 (April 29th - May 13th) . . . . . . . . . . . . . . . . . . . . . . . . . . 407.9.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.9.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.9.3 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.9.4 Timesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.9.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8 Project Summary 428.1 Project Burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2 Work Time Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.3 Project Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

9 Conclusion 459.1 Future Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

A Appendix 46A.1 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.2 System Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

A.2.1 UWP - Windows 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2.2 Android app - ASUS . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

vi

List of Figures

2.1 The Scrum process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 Expected project burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.1 System diagram. Project scope outlined within the blue dashed box. . . . . . . . . 135.2 Xamarin.Forms Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3 MVVM framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.4 Abstracted peripheral class compatible with SQLite3 . . . . . . . . . . . . . . . . 165.5 Navigation diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.6 Login page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.7 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.8 Device page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.9 Details page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.10 Modify page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.1 Burndown chart for sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2 Burndown chart for sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3 Burndown chart for sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.4 Burndown chart for sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.5 Burndown chart for sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.6 Burndown chart for sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.7 Burndown chart for sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.8 Burndown chart for sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1 Actual project burndown chard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2 Percentage of time spent on categories . . . . . . . . . . . . . . . . . . . . . . . . 438.3 Project work time overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

vii

List of Tables

2.1 Development team roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Software & tools used in the project . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Sprints deadlines and significant dates . . . . . . . . . . . . . . . . . . . . . . . . 53.2 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 User stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1 Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Risk mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Incident log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 Database tables in local database . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7.1 Sprint 0 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257.2 Sprint 1 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.3 Sprint 2 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.4 Sprint 3 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.5 Sprint 4 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.6 Sprint 5 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.7 Sprint 6 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.8 Sprint 7 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.9 Sprint 8 - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1 Project - Time estimates vs actual values . . . . . . . . . . . . . . . . . . . . . . . 438.2 Project - Work overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.1 User authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 User logged in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.3 Device list page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.4 Device home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.5 Variables page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.6 Actions page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.7 Reports page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.8 Device Information page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53A.9 User logged in on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.10 User logged in on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.11 Device list page on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.12 Device home page on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

viii

A.13 Variables page on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.14 Actions page, on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.15 Reports page on Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.16 Device Information page on Android . . . . . . . . . . . . . . . . . . . . . . . . 60

1

Chapter 1IntroductionThis document describes the system design, implementation and development process of theproject R&D Client for Bionic Prosthetics in cooperation with the Research & Development(R&D) department at Össur hf. The project is a final project in Computer Science at ReykjavíkUniversity.

1.1 About the ProjectThe aim of this project is to create a cross-platform application, thought of as a simple

working tool for Össur’s specialists, capable of connecting to Össur’s bionic prosthetic de-vices to configure, receive information and perform simple actions on them through wirelesscommunications. This application has the development work name TÝR, with a reference to theone-handed Norse god with the same name. The application will improve upon Össur’s currentiOS application, Össur Logic, and some simple working software tools currently being used forresearch and development of new devices.

TÝR will allow Össur’s specialists to collect data from one or more devices simultaneously,with focus on next generations of bionic devices. Also, the application is able to configure thedevices as needed and send collected data to a remote data storage. Current bionic prostheticscan send sensor data and events through Bluetooth Low Energy (BLE) technology to the ÖssurLogic application, running on iOS devices. The next generation of bionic devices will supportWi-Fi communications so that will be a key feature in TÝR.

In general, the application helps Össur’s R&D specialists, quality assurance and assem-bly personnel to work more efficiently and effectively with bionic prosthetic prototypes duringdevelopment. The application also focuses on expandability, allowing Össur to add new com-munication methods and features with relative ease.

1.2 About Össur hf.Össur hf. was founded by the prosthetist Össur Kristinsson in 1971. It is a world leader in

developing and manufacturing prosthetic devices and bracing products. Currently, it employsaround 2300 people in 18 locations in the Americas, Europe, and Asia, with headquarters inReykjavík.

Bionic prosthetic devices greatly enhance the capabilities of prosthetics, allowing them tobetter mimic the range of motion and haptics by using advanced electronics and electromechan-ical technologies. These bionic devices, first introduced by Össur in 2005, have over the lastdecade evolved immensely with the improved performance of microcontrollers and wirelesscommunications. The goal of Össur is to improve the quality of life of people across the worldwith the use of their products.

2

Chapter 2Methodology

2.1 RolesAt the end of the project term, the team is responsible for delivering a functioning product,

a Xamarin.Forms cross-platform client application for the R&D department at Össur, focusingmainly on delivering Universal Windows platform (UWP) application.

2.1.1 Development TeamIn the beginning of the project, all team members work together on the design of the appli-

cation. After that, Skúli and Jón will focus on back-end functionality while Egill and Benediktwill focus on the front-end of the application. The plan is to use peer programming when pos-sible.

The team will be in good contact with its supervisor and try to meet with him weekly. Theteam will present the project on three status meetings with the teacher, supervisor and examinerand at the final presentation on May 16th.

Table 2.1: Development team roles

Name Primary Focus

Benedikt Valur Árnason Front-end

Egill Anton Hlöðversson Front-end / Scrum master

Jón Söring Back-end

Skúli Þór Jónasson Back-end

2.1.2 Product OwnerKristján Þór Finnsson, a software developer at Össur, is the product owner. He is responsible

of determining the overall direction of the project, what features it should have and the priorityof its requirements. The team plan on meeting with him every Friday for around half an hour,more if necessary. The team will also be in contact with Karl Andrés Gíslason, another softwaredeveloper at Össur, regarding technical matters.

2.1.3 Scrum MasterEgill Anton Hlöðversson is the Scrum master of the project. He is responsible for removing

impediments during the project period and taking care of and protecting the team from externalinterference. He will also have an important role as a front-end developer for the application.

CHAPTER 2. METHODOLOGY 3

2.2 ScrumFor this project, the Scrum software development process (Figure 2.1) will be used. It is an

iterative and agile approach that helps the project team come up with a real, working softwarerepeatedly by focusing on delivering the highest business value.

The whole project is divided into sprints, each 2 weeks long. First, all the functional andnon-functional requirements the project needs to fulfill are turned into user stories. The storiesare collected into a product backlog where they are prioritized. Before each sprint, some storiesfrom the product backlog will be chosen to be implemented in the upcoming sprint. They arecollected into a sprint backlog where they are broken down into smaller tasks. The main goalis that at the end of each sprint, some working product should be ready for display. Figure 2.1below describes the Scrum process.

Figure 2.1: The Scrum process

The estimated work for each person in each sprint will be approximately 40 hours. Theteam can increase or decrease their work with respect to team members’ workload in classesand other responsibilities.

The team will meet twice a week at Össur’s headquarters, on Wednesdays and Fridays, andmore often when necessary. The team thinks it is preferable to work there as they have access tothe product owner and can easily talk about and help each other with difficulties. The memberswill also work on the project separately or in pairs during each sprint and are expected to de-liver additional 8 hours of work outside of scheduled workdays. Communication between teammembers will be through instant messaging.

During workdays, a short daily scrum meeting will be held to check how everything is go-ing, what each member has been doing and what he is going to do over the next days.

On Friday at the end of each sprint, a sprint review meeting with the product owner willbe held where the team reviews the results of the sprint. Then, the team will hold a short ret-rospective meeting to go over what went well and what could have gone better during the sprint.

Before each sprint, the team will hold a sprint planning meeting where user stories fromthe product backlog are selected for the upcoming sprint. The stories are then broken down

CHAPTER 2. METHODOLOGY 4

into smaller tasks, estimated in hours. Then if necessary, the product backlog can also be re-estimated and re-prioritized in collaboration with the product owner.

The estimated remaining hours for each task are updated daily in the sprint backlog. Also,the total hours worked are recorded in a separate work time log. The members will divideamongst themselves what tasks they will work on from the sprint backlog.

The team estimates a total of 1280 hours for the whole project (4 team members * 8 sprints* 40 hours/sprint), of which 950 hours (75%) are planned for application development, design,testing etc. The remaining time is allocated for documentation, presentations and project ad-ministration.

2.3 Software & ToolsThe software and tools listed in table 2.2 are used in the project for documentation, pro-

gramming, testing and design.

Table 2.2: Software & tools used in the project

Software & tools Usage

Balsamiq Wireframes design

BitBucket Hosting service

CSVhelper Library for reading & writing CSV files

Draw.io Diagrams and design

GhostDoc Enterprise Code documentation

Git Revision control

Google Docs Documents & manuals

Google Sheets Scrum & time documentation

Microsoft Azure Host for Össur Bionic Cloud

Microsoft Visual Studio 2017 Development environment

Overleaf Final & status reports

OxyPlot Cross-platform plotting library

Plotly Charts and plots

SQLite3 Local database

Xamarin.Forms Cross-platform UI framework

xUnit Unit testing

5

Chapter 3Organization

3.1 Reports and DeadlinesDuring the course of the project, the team is expected to hand in four reports to the course

teacher, supervisor and examiner. Three of them are status reports, which are due two daysprior to the status meetings, and finally the final report is due on May 12th.

Each sprint is expected to take two weeks, from Saturday to Friday two weeks later. Thewhole project time can therefore be broken down into nine sprints. The first sprint (no. 0) is ex-pected be less organized than the others while planning the project, gathering the requirements,designing etc. The other sprints (no. 1-8) should be more organized and follow the Scrumframework. The final sprint (no. 8) is expected to be used to finish the project and the finalreport so all user stories should be completed by that time.

The sprints are shown in table 3.1 below with their start and end dates, along with the mainevents, reports and their expected hand in dates. The table also shows what user stories areworked on during each sprint.

Table 3.1: Sprints deadlines and significant dates

Sprint Start Finish User Stories Hand-in / Meeting Deadline

0 Jan. 1st Jan. 20th None Final project description Jan. 18th

1 Jan. 21st Feb. 3rd 1-A, 2-A, 3-A Work plan introduction Jan. 25th

Work schedule draft Jan. 25th

2 Feb. 4th Feb. 17th 3-A, 4-A, 5-A Student presentation Feb. 7th

Project status report Feb. 13th

First status meeting Feb. 15th

3 Feb. 18th Mar. 3rd 6-A, 7-A, 8-A None −

4 Mar. 4th Mar. 17th 8-A, 9-A, 10-A Project status report Mar. 11th

Second status meeting Mar. 13th

5 Mar. 18th Mar. 31st 10-A, 11-A None −

6 Apr. 1st Apr. 14th 11-A, 12-B None −

7 Apr. 15th Apr. 28th 13-B, 14-C, 15-C, 16-C None −

8 Apr. 29th May 12th None User manual May 6th

Operation manual May 6th

Project status report May 6th

Third status meeting May 8th

Final product hand-in May 12th

Final presentation May 16th

CHAPTER 3. ORGANIZATION 6

3.2 Product BacklogUsing the initial project outline and first meetings with the product owner the team created

the product backlog with stories that were designed to fulfill the product owner’s requests. Theteam weighted the stories using planning poker and ordered them by priority as a suggestion forthe product owner. The current prioritization was accepted by the product owner on the January27th. The product backlog was revised in sprints 5 and 6.

Table 3.2: User stories

Priority Sprint Story Points Status

1-A 1 I as a researcher need to be able to discoverone or more peripherals so I can establishconnection to the peripheral.

5Donein sprint 1

2-A 1 I as a researcher need to be able to connect toone or more peripherals so I can access datafrom it/them.

5Donein sprint 1

3-A 1-2 I as a researcher need to be able to viewvariables information from a specificperipheral so I can explore the data in a simpleand convenient way.

13Donein sprint 2

4-A 2 I as a researcher need to be able to log in to theapplication with user name and password so Ican use the application and sync data to thecloud service.

3Donein sprint 2

5-A 2 I as a researcher need to be able to storecollected data in a local database so I canaccess the data after acquisition.

8Donein sprint 3

6-A 3 I as a researcher need to be able to updatevariables for a specific peripheral so I canconfigure the specific variables according toneed.

8Donein sprint 3

7-A 3 I as a researcher need to be able to view aperipheral-specific start page when connectedto a peripheral so I can to view the status ofthat peripheral.

8Donein sprint 3

8-A 3-4 I as a researcher need to be able to exportspecific periods of data for specific peripheralsto the cloud service so I can store remotely itand use for analysis.

8Donein sprint 4




9-A 4 I as a researcher need to be able to get a reportfrom a particular peripheral using theapplication so I can explore the data in asimple and convenient way.

5Donein sprint 4

10-A 4 I as a researcher need to be able to enableautomatic data syncing to the cloud service so Ican use the data for for analysis.

5Donein sprint 5

11-A 5 I as a researcher need to be able to exportspecific periods of data for specific peripheralson local machine so I can import data intoother programs.

3Donein sprint 6

12-B 6-7 I as a researcher need to be able to initiateactions in peripherals so I can perform specificactions on the device (i.e. calibration).

13Donein sprint 6

13-B 6-7 I as a researcher need to be able to view eventinformation from peripherals so I can exploreperipheral events in a simple way.

5Donein sprint 7

14-B 7 I as a researcher need to be able to storecollected events in local database so I canaccess them after acquisition.

5Donein sprint 7

15-C 7 I as a researcher need to be able to view ahistorical graph of a selected variable so I canvisualize the variable value over time.

13Donein sprint 7

16-C 7 I as a researcher need to be able to run theapplication on Android so I can use theapplication on my Android phone or tablet.

3Donein sprint 7

17-C 6 I as a researcher need to be able to discover aperipheral through Bluetooth Low Energy(BLE) using the application so I can establishconnection to the peripheral through BLE.

13 Canceled

18-C 6 I as a researcher need to be able to connect to aBLE peripheral so I can access data from theperipheral.

5 Canceled

19-C 8 I as a researcher need to be able to add AMQPconnected peripheral so I can access data fromthe peripheral.

13 Canceled




20-C 8 I as a researcher need to be able to initiateconnection to peripheral through AMQP so Ican access data from the peripheral.

5 Canceled

3.3 Expected Project BurndownThe team estimates a total of 950 hours to work on development, as mentioned in Chapter

2.2. Initially, the project had a total of 130 story points, which meant the group had approxi-mately 7.3 hours for each story. Expected burndown velocity for sprint 1 through 5 was plannedas 22 story points/sprint and reduced to 10 points/sprint for sprints 6 through 8, due to examperiods and increased proportion of time spent on reports.

During the course of the project, two new stories were added to the backlog. Therefore, thetotal number of story points increased to 146. See chapter 8.1 for the actual project burndown.

Figure 3.1: Expected project burndown

9

Chapter 4Risk AnalysisThe team performed a risk analysis on February 12th for foreseeable problems (Table 4.1). Eachrisk is comprised of a probability and impact which are ranked on a scale from 1 to 5. The mul-tiple of these two define the total risk which defines the order of the risk table.

Designated handlers work on reducing the probability and/or impact of each risk and logall mitigations (Table 4.2) made to reduce the risk. Also, this chapter includes an incident log(Table 4.3) where incidents are noted along with the group’s response.

Table 4.1: Risk analysis

Total Probability Impact Risk Reaction Handler

15 5 3 Final Exams Benedikt and Egill are unavail-able for some days. Set work-load in sprint accordingly assoon as exam dates are released(March 6th). When they have"free" days they will work onthe project, including the Easterholidays. Skúli and Jón will tryto work more on the project in-stead.

Benedikt

12 3 4 Product ownerchanges projectscope orrequirements

Adjust requirements incompliance with productowner and instructor.

Egill

10 2 5 Natural disaster(Jón works at theIcelandicMeteorologicalOffice)

Jón will be excused while hemakes arrangements at work.Speak to product owner and in-structor about reducing the sizeof the project scope. Jón es-timates his availability for thisproject.

Jón

10 5 2 Workload inother courses

Plan ahead to prevent too muchwork. Alert group membersand/or adjust workload in sprintif necessary.

Benedikt

CHAPTER 4. RISK ANALYSIS 10

Table 4.1: Risk analysis

Total Probability Impact Risk Reaction Handler

8 2 4 Össur BionicsCommon PCLlibrary forcommunicationswith bionicdevices notworking asexpected

Pressure Össur to deliver work-ing code. Reduce the size ofthe scope if necessary. Use pre-programmed "dummy" devicesif no real devices are available.

Egill

6 3 2 Illness Try to work at home if illnessis minor. If illness is serious,speak to product owner and in-structor about reducing the sizeof the project scope.

Egill

6 2 3 Technicalenvironmentproblems(Xamarin.Forms,Git/Bitbucket,Visual Studio)

Try to find solutions together. Ifnecessary, re-evaluate the sprintbacklog. If critical problems,talk to product owner about re-ducing the size of the projectscope.

Jón

4 2 2 Computerproblems

Seek help from Össur's IT de-partment. If necessary, get ac-cess to another computer fromÖssur or home.

Skúli

3 3 1 Bad weather ortravel problemson the way fromAkranes

Benedikt will work from homeand communicate via Skype ormessenger.

Benedikt

3 1 3 Can’t connect toBionic Cloudthough API

Seek help from product own-ers and developers from Össurabout API connections.

Skúli

3 1 3 Internet problems(Bionic Cloud,Git/BitBucket,communications)

Use 4G from cell phones. Theapplication should be able toconnect to devices offline. Seekhelp from Össur's IT depart-ment .

Jón

2 1 2 Product ownerquits

Quiting product owner workswith the group to find anotherÖssur employee to take over asproduct owner. Reestimate thescope of the project if neces-sary.

Egill


4.1 Risk Mitigation

Table 4.2: Risk mitigation

Date Risk Action Handler

10/03/2017 Natural disasters Jón’s supervisors aware of commitment toproject and other employees of IcelandicMet Office have been taught to perform ba-sic maintenance, decreasing the possible im-pact on the project. Impact reduced from5 to 4.

Jón

10/03/2017 Final Exams Benedikt will take his exams on April 4th

and 21st. Egill will take his exams on April7th and 10th. According to that, at least oneof them will be able to attend weekly workmeetings over the exam period, includingthe Easter holidays (April 12th-18th). Im-pact reduced from 3 to 2.

Benedikt

29/03/2017 Can’t connect tothe Bionic Cloudthrough API

Connectivity to Bionic Cloud through APIwas completed. Probability/impact re-duced to 0.

Skúli

14/04/2017 Össur CommonPCL backend notworking asexpected

Cooperation between the group and prod-uct owner, who is the chief programmer forthe PCL package, has resulted in a versionof the library that fulfills the needs for thescope of the project. Probability reducedfrom 2 to 1.

Egill

21/04/2017 Final Exams Benedikt and Egill have completed their ex-ams. At any given time over the exam pe-riod, either of them was able to participate indevelopment. Probability/impact reducedto 0.

Benedikt

21/04/2017 Workload in othercourses

Bendikt and Egill have completed theircourses. Probability/impact reduced to 0.

Benedikt

24/04/2017 Technicalenvironmentproblems

The group was able to produce working ver-sion of the application running on iOS, An-droid and Universal Windows Platform. Im-pact reduced from 2 to 1.

Jón

26/04/2017 Product ownerchanges projectscope orrequirements

Meetings between product owner and grouphave clarified and further agreed upon thescope and requirements of the project.Probability reduced from 3 to 1.

Egill


4.2 Incident Log

Table 4.3: Incident log

Date Risk Incident Action Handler

18/01/2017 Computerproblems

Skúli’s computerwas behavingstrangely and slowly

Össur’s IT depart-ment increased hiscomputer memory.

Skúli

20/01/2017 Illness Jón’s family mem-bers were ill

Jón worked fromhome

Jón

01/02/2017 Illness Benedikt was ill Benedikt worked onreports from home

Benedikt

24/02/2017 Badweather

Benedikt could notcome to Reykjavík

Benedikt workedfrom home

Benedikt

01/03/2017 Illness Jón was ill Sprint 4 was wellon track, no adjust-ments needed.

Jón

10/03/2017 BionicsCommonPCL

Problems receivingdata from a bionicdevice through WiFi

Meeting with prod-uct owner to discussissue.

Egill

15/03/2017 Hardwareproblems

Egill’s computercrashed while in-stalling VisualStudio 2017

Egill re-installedWindows and VisualStudio.

Egill

04/04/201721/04/2017

Finalexams

Benedikt did notattend as he waspreparing for hisexams

Benedikt resumedparticipation afterhis exams,

Benedikt

05/04/201707/04/2017

Finalexams

Egill did not attendas he was preparingfor his exams

Egill resumed par-ticipation after hisexams.

Egill

13

Chapter 5Design

5.1 System ArchitectureThis project is implemented using Xamarin.Forms in Visual Studio 2017 IDE. The code

is written in C# and XAML and follows the MVVM architectural pattern. Össur providesa Portable Class Library (PCL) called Össur Bionics Common PCL that has all the necessaryservices to connect to the prosthetic peripherals and to a cloud service in Microsoft Azure calledÖssur Bionic Cloud through a simple REST API. All the data received from the peripherals canbe stored in a local SQLite3 database. They can also be exported to the cloud service throughthe API. This chapter gives a better overview about the implementation of the application andother useful guidelines.

Figure 5.1: System diagram. Project scope outlined within the blue dashed box.

CHAPTER 5. DESIGN 14

5.2 Xamarin.FormsXamarin.Forms is used to implement cross-platform applications. This allows the team to

create a single application that can be built for iOS, Android, and UWP with a shared C# andXAML codebase as seen in figure 5.2. This allows anyone that has a background experiencein C# programming to jump straight into implementing a cross-platform application withoutspending valuable time learning Android- or iOS-specific programming languages.

Figure 5.2: Xamarin.Forms framework 1

5.2.1 MVVMWithin the Xamarin.Forms community there has been an encouraging movement using the

MVVM(Model-View-View-model) architectural pattern (Figure 5.3) over e.g. MVC (Model-View-Controller) or MVP(Model-View-Presenter). The two main benefits using MVVM are:

1. Complete separation between the view and model, which has the benefits of being capa-ble of changing the model without having to change the view and vice versa.

2. It can support automatic two-way data binding between the view and the view-model.

Figure 5.3: MVVM Framework 2

1Xamarin Product Website - https://www.xamarin.com/platform2Introduction to Xamarin.Forms and Lessons Learnt - Michael Ridland

https://www.slideshare.net/rid00z/introduction-to-xamarinforms-and-lessons-learnt


MVVM is only an architectural pattern, which means that developers are not restricted tofollow it completely. In this project the team will try to adhere to these main guidelines:

• Each view has only one view-model that it binds to.

• Have minimum code in the xaml.cs class files.

• Try to use commands over event functions.

• All models are ObservableObjects and use the INotifyPropertyChanged interface.

• All displayed lists are ObservableRangeCollection that have better performance thanObservableCollection.

• Instead of using OnPropertyChanged in the setters, use SetProperty(ref memberVari-able, value); which improves overall readability.

Even though MVVM is a getting more popular with every year, it is not perfect. Forexample, this project is using the Össur Bionics Common PCL library that does not fully sup-port double-binding. In those cases, custom classes will be created to facilitate double-bindingand MVVM best practices.

5.3 Back-end DesignThe service layer (back-end) of the project will provide connections to bionic devices using

functions and classes from Össur Bionics Common PCL, which encapsulates the communica-tion protocols for the devices. The information from the devices can then be received and sentto up the user interface for inspection and analysis. The devices can also be configured accord-ing to the specialists’ needs. The data is saved in a SQLite3 database and can also be saved atÖssur’s cloud service, the Bionic Cloud, for more elaborate data analysis.

5.3.1 Local Database StorageA requirement set forth by the product owner is the ability for the application to store infor-

mation about the devices and its variables while not connected to the Internet. As the applica-tion supports multiple platforms the local database must also be cross-platform and preferablyone implementation should be used. At the time of application development, the only viabledatabase is SQLite3 which bears some resemblance to the .NET Entity Framework. This allowsus to create classes in C# and store them in the database without having to use SQL syntax. Thiscross-platform version of SQLite3 does however not support any foreign key relations and stor-ing the original Bionics Common PCL classes Peripheral, Variable, etc. is not possible dueto the fact that these classes contain types of variables that are not compliant with Sqlite3. Toimplement the database storage of peripherals and their variables specific database class ver-sions of these must be created (Figure 5.4). Conversion to and from these classes is done atthe data layer. The data stored in the local database is described in Table 5.1. It describes the


Figure 5.4: Left: Abstracted peripheral class compatible with SQLite3Right: Original Peripheral class provided by Bionics Common PCL.

database tables, what their compatible Bionics Common PCL classes map to, what aspects ofthe application they are associated with and if they can be synced to the Bionic Cloud.

Table 5.1: Database tables in local database

Table Bionics Common PCL class Associated with Synced to cloud

PeripheralDb Peripheral Bionics peripheral Yes

VariableDb Variable Bionics peripheral Yes

EventDb EventBionics periph-eralApplication

Yes

ReportDb Report Bionics peripheral Yes

UserDb User - No

5.3.2 AuthenticationThe product owner requested that authentication into the application would be linked to the

Bionic Cloud. Therefore, each member registered in the cloud service has access to the appli-cation. The Bionic Cloud API exposes login services that are linked to Össur’s authenticationservers. This requires that the application needs Internet access to complete the log in. Whenthe user authenticates, he receives a special one-time API key. This key grants him permissionto sync data from the application to the cloud service.

To increase the usability of the application, user credentials are stored in a local databasewith hashed passwords to allow the user to log in to the application, even though it is not con-nected to the Internet. This presents a slight security issue where a user with enough knowledgecould edit the applications login cache, which is stored in database. Doing so could grant theuser access to the application but will not allow him to sync any data to the cloud service, as theuser did not receive the essential API key from the cloud service.


5.3.3 Syncing Data to Bionics CloudAll new data collected by the application and saved in a the local database can be synced to

the cloud service, both manually and automatically. Table 5.1 shows what types of data from thelocal database can be synced. When data is synced to the cloud it is marked with a time-stampto prevent it from being synced more than once.

The application tries to sync all new data automatically every 10 seconds. For each deviceconnected to the application, the user can choose to enable or disable automatic syncing at anytime while connected to the device. All events associated with running the application itselfwill automatically be synced, as long as a user is authenticated through the cloud service.

The user can also choose to sync all new data received from a connected device manually(as a single action) if the automatic sync is disabled.

5.4 Navigation DiagramThe following chart displays the flow within the application and how the different pages are

interconnected. It can be noted that once a user is logged in, the navigation menu (sidebar) isavailable to him. This navigation menu is the primary way to navigate through the application.

Figure 5.5: Navigation diagram

5.5 Mock-upsMock-ups for the core functionalities of the application were made for the application.

These mock-ups do not give a detailed description of how each page will look like but themain idea is to give a general idea of what each page will represent and display.


5.5.1 LoginThe application starts up with a login screen. That way, it is certain that only users certified

by Össur can use the application. The login screen is very simple. It is simply two input boxes,one for the user name and the other for the password and one login button.

Figure 5.6: Login page

5.5.2 HomeAfter the user has logged in he is taken to the home page. Here he can see information about

himself and information about recent devices he has worked on. On the left of the screen thereis a sidebar. That sidebar will contain things such as a logout button, a list of connected devices,and a link to the scanning page.

Figure 5.7: Home page


5.5.3 DevicesThis is the page used to search for bionic devices in close proximity. Here, the user can

push the Scan button to scan for devices. The program will then display all devices availablefor connection. The user can then decide to connect to any given device and from there he canget more details on that device.

Figure 5.8: Device page

5.5.4 DetailsOnce a user is connected to a device and has clicked the Details button, he is greeted with a

page that contains the basic information of that device and a list of all of its variables. The listof variables will most likely be quite extensive so the plan is to include a search bar so the usercan search for specific variables from the list. The user can also change the value of a specificvariable by choosing the Modify button next to it.

Figure 5.9: Details page


5.5.5 ModifyThis page will most likely be somewhat different between variables, depending on its type.

E.g. for boolean variables, a single toggle button would be enough while a text box or a sliderwould be appropriate for variables with numerical or string values. This page should alsoinclude information about the variable type, its maximum and minimum allowed values andpossibly display a history of changes made to the variable. The new value can then be sent tothe device by pushing the Confirm button.

Figure 5.10: Modify page

21

Chapter 6Testing

6.1 Back-end Unit TestsThe business logic in the service layer and the data access layer was unit-tested using xUnit

testing framework. All functions regarding the local database, connections with devices and theBionic Cloud were tested carefully. The unit tests were made to check for functionality errorsand will play an important role in future development of the project. No major bugs in the codewere discovered. The code coverage for the service and access layers functions exceeds 80%.

6.2 System TestsManual system tests were performed, both on the UWP version and the Android version of

the applicaton. In total, 40 tests were performed on each version, both for the functionality ofthe application itself and also the communication with the local database, a bionic device pro-totype and the Bionic Cloud. The results from both the system tests can be found in AppendixA.2. Each test consists of a description of some functionality the user is asked to perform inthe application, the expected behavior from that functionality and the actual behavior. If somedifferences were discovered between the expected and the actual behavior, they were recorded.

The UWP version of the application was tested on a Windows 10 operating system and anactual bionic device prototype, connected through WiFi. The results can be found in AppendixA.2.1. Two minor bugs were found in the tests which were fixed soon after, regarding illegalvalues for a variable (see table A.5). All other functionality worked out as expected.

The Android version of the application was tested on a ASUS Zenpad C 7.0 and a prepro-grammed "dummy" device from the Bionics Common PCL library, mocking the functionalityof a real bionic device. The results can be found in Appendix A.2.2. Most of the functionalitytested worked as expected but minor bugs were found when changing the value of a variable(Table A.13). Also, the search boxes didn’t always work as well as it did in the UWP version.Those bugs were not considered significant. All other functionality worked as expected.

CHAPTER 6. TESTING 22

6.3 User Tests

6.3.1 IntroductionA specialist from the R&D department in Össur was asked to perform a simple think-aloud

test and given a brief introduction about TÝR. The main purpose of the test was to find if somefunctionality problems occurred or if there were any specific features lacking in the application.Those results could be used for improving the usability of future versions of the project. TheUWP application was used for testing.

6.3.2 ProcedureThe user given the following introduction:

"Welcome and thank you for your participation. The main goal of this test is to assessthe functionality and accessibility of our application, TÝR. Our application is designed for theR&D specialists when developing new versions of bionic devices. When using the application,the specialist can receive and collect data from a specific peripheral in a simple manner andperform simple changes and actions on the device. The application supports WiFi communica-tions with the bionic devices.The estimated time for this exercise is about 10 minutes. You can quit at any time without anyrepercussions. This exercise contains 11 tasks to solve, one at a time. Please let us know everytime you believe you have completed a task. After all the tasks have been completed, we wouldlike to ask you some questions about your experience with the application. The results from thetest will be used in further improvements of the application."

The following task were performed by the user:

1. Connect to a device.

2. Change a value for the variable Accelerometer x calibration gain.

3. Disable Toelift in swing.

4. Choose the actions for moving the motor all the way up and down for a connected device.

5. View the latest Speed Histogram Report.

6. Create a new Log Report and view it.

7. View the events from the device.

8. Manually sync data to the cloud.

9. Find the name of the current user.

10. Find the information about the application.

11. Disconnect from the connected device.

12. Log out from the application.

CHAPTER 6. TESTING 23

At the end of the test, the user was asked the following questions:

• Were there any tasks that were more complicated to perform than others?

• Did you think the UI was comfortable in use?

• Which were the biggest upsides/downsides of the application?

• Was there anything missing in the application?

• Is there anything you would like to add?

6.3.3 ResultsThe user had no major problem solving the tasks. Some of the tasks took a very short time to

solve and none took more than 90 seconds. The user was generally pleased with the applicationand its functionality and looks. His main critique was as follows:

• Visibility of the Back and Save buttons is lacking in native UWP applications. The userwould have wanted a more noticeable Back button and closer to the main frame of theapplication. Native buttons in UWP lack contrast and labels and buttons have a verysimilar appearances.

• Lack of conformation that a updated variable has been transmitted to a connected de-vice. User would like to get better feedback whether or not transmitting a variable wassuccessful.

• When asking for a new report, the newly created report should be more apparent in thelist, especially when the list is long. It would be better if the newest report appeared atthe top of the list, similar as in the Events list.

• Information about the authenticated user is only available from the Home page, userwould like to see that information available from the sidebar.

• The user would like to go straight to the device Detail page after pressing the Connectbutton instead of having to press Manage.

• The user would like to be able to select items from list by pressing the row itself, ratherthan having to press a button located on the far right of the row.

These points can be used in future improvements of the application.

24

Chapter 7Sprints

7.1 Sprint 0 (January 7th - January 20th)

7.1.1 ThemeIn this initial sprint, the team members focused on getting the working environment (Visual

Studio 2015 Update 3 + Xamarin.Forms) up and running on their laptops. During the sprintthe team spent time analyzing the project scope and the requirements in collaboration with theproduct owner. Finally, the team worked on documentation and initial design of the project.This sprint was not organized as a regular scrum sprint because of this primary work and setup.

7.1.2 SummaryThe team started organizing each team member’s responsibilities and roles. The team

structured a work time management log where they will keep track of how many hours willbe spent on this project.

The product backlog was created in cooperation with product owner where he helped withprioritizing the requirements. Soon after the team organized the scrum workflow based on thebacklog.

The rest of the sprint, the team focused on getting more familiar with Xamarin.Forms.

7.1.3 RetrospectiveThe team started well coordinating itself and the spirit within the team was good. No special

problems were encountered in this sprint except for minor technical difficulties in the beginningwhen getting Xamarin.Forms up and running properly.

Unfortunate events / improvement needed• Date for a formal meeting was yet to be established with the team supervisor.

Other events• Few sample mock-ups were generated and discussed.

• Elevation statements were created.

• Work plan introduction.

• 4 meetings with the product owner.

• 1 brief meeting with the team supervisor.

CHAPTER 7. SPRINTS 25

7.1.4 Timesheet

Table 7.1: Sprint 0 - Work overview

Team Member Total Work in Sprint (Hours) Total Work in Project (Hours)

Benedikt Valur 28 28

Egill Anton 33 33

Jón Söring 27 27

Skúli Þór 32 32

Total 120 120


7.2 Sprint 1 (January 21st - February 3rd)

7.2.1 ThemeThe main goal for the sprint was to get basic functionality working on the application us-

ing pre-programmed "dummy" devices. This includes scanning for and displaying availableperipherals, connecting to them and displaying the values of their variables.

7.2.2 SummaryThe team completed user stories 1-A, 2-A and started working on 3-A. In addition to that,

the team had to prepare a work plan introduction and a draft of a work schedule to hand in to theteam supervisor. A local database for the project was setup using SQLite3, and finally severalmock-ups were designed to get a better perspective for the final product.

7.2.3 RetrospectiveThe team functioned well and completed most of the tasks, which were originally planned

in the beginning of the sprint. The only point that the team had to consider was to increase thenumber of estimated hours for the view for the peripheral variables and prolong that work intothe next sprint.For now, the application can only display the basic view without any specific style. The teamwill continue to improve the design of the views as the projects continues in development.

Unfortunate events / improvement needed• Jón Söring was at home on January 20th due to illness within his family and therefore not

able to attend scheduled meeting that day.

• Benedikt Valur was sick on February 1st and therefore not able to attend scheduled meet-ing that day.

• The work time management document needs to be improved, so the work for the projectcan be split into further specific categories.

Other events• Meeting was held with with team supervisor on the 28th of January. Decision was made

to try to have weekly meetings at Össur on Fridays after lunch every week.

• Skúli was having problems with his computer and decided to increased its memory. Thisresulted in an improved computer performance.

• Meeting with the project owner was held both Fridays and the former Wednesday.

• A newer version of Bionics Common PCL library was integrated into the project.

• Further experimentation and training was done on Xamarin.Forms.

• Mock-ups created, improved and refined.


7.2.4 Timesheet



Benedikt Valur 36.5 64.5

Egill Anton 49 82

Jón Söring 51 78.5

Skúli Þór 49 81

Total 185.5 306

7.2.5 Burndown Chart

Figure 7.1: Burndown chart for sprint 1


7.3 Sprint 2 (February 4th - February 17th)

7.3.1 ThemeIn this sprint, the team continued to focus on improving the connection with the local

database and also refactor the code so it would follow the MVVM architectural pattern bet-ter. Finally, the team continued to work on displaying variables from the peripherals.

7.3.2 SummaryThe team completed user stories 3-A, 4-A and started working on 5-A. Even though most

of the database functions were completed, some minor improvements and testing was missing.Some code refactoring took place so the code would follow the MVVM architectural patternbetter.The team prepared for the student presentation at the university and also for the first statusmeeting.

7.3.3 RetrospectiveMore time was spent on documentation than originally planned. This resulted in the story

5-A not being fully completed in the sprint so it will be completed in Sprint 3. The team agreednot to make any significant changes to each other’s code without involving the code’s author.

Unfortunate events / improvement needed• Code commenting and documentation need further improvement.

• Some communication problems came up with the project owner. The owner came for ameeting one day and stated that he would implement most of the back-end himself whilethe team would only focus on the front-end. The team had worries about decreasing thesize of the scope of the project so the project owner agreed that the team would continueimplementing the back-end services as planned in the beginning.

• The team need a better working environment due to poor air conditioning in the currentmeeting room.

Other events• Login page and functionality was implemented, using Bionic Cloud API authentication

and local database.

• Several additional pages were added. (Home and About pages).

• Local database was developed further and tested.

• MVVM code refactoring done on the Master Detail Page, Login Page and Home Page.

• Student presentation took place on February 7th.

• The first status meeting took place on February 15th.


7.3.4 Timesheet




Egill Anton 74.25 156.25

Jón Söring 47.85 126.35

Skúli Þór 50.75 131.75

Total 222.10 528.10




7.4 Sprint 3 (February 18th - March 3rd)

7.4.1 ThemeThe team focused on implementing UI views for displaying and changing variables, dis-

playing specific information about the connected peripheral and syncing new data to the BionicCloud service for further analysis.

7.4.2 SummaryThe team completed user stories 5-A, 6-A, 7-A and started working on 8-A. The overall

work went well as the team finished the UI aspects for variables so now it’s possible to viewand update the variables. Syncing data to cloud service and saving to local database is nowworking correctly.The focus for the next sprint is to connect the UI view and the back-end services better together.So, whenever the variables are edited in the UI, they can be saved directly to the local databaseand sent back to the peripheral.

7.4.3 RetrospectiveThe team accomplished most of the desired functionalities. Even though there were few

absences, the team sprint spirit remained strong.

Unfortunate events / improvement needed• Jón Söring had to leave early on February 24th due to family matters.

• Benedikt did not attend on February 24th due to storm (he lives in Akranes).

• Jón Söring did not attend the working sessions on Wednesday March 1st due to illness.

• The sprint backlog was rather imprecise. The stories need to be broken down into moredetailed tasks when possible and the backlog hours updated more frequently.

• The team need to keep a better overview of time spent on meetings, documentation etc.in the sprint backlog.

Other events• Short meetings were held with project owner each workday.

• A meeting with the team supervisor was held on the March 3rd.


7.4.4 Timesheet



Benedikt Valur 44 157.75

Egill Anton 52 208.25


Skúli Þór 38.25 170

Total 152.25 680.35




7.5 Sprint 4 (March 4th - March 17th)

7.5.1 ThemeFor the second status meeting, the team focused on improving their presentation techniques

and structure from the first status meeting. The team also focused on the user stories for ob-taining and viewing reports from a peripheral. Finally, the team saw that improvements wereneeded in the functionality for syncing data to the cloud service by allowing both manual andautomatic syncing.

7.5.2 SummaryThe team completed user stories 8-A and 9-A. Story 10-A was expected to be implemented

but the team decided to move it to the following sprint, due to time needed to prepare for thesecond status meeting. Össur supplied the team with a bionic device prototype to test commu-nications against, with some success but some work still needed.

7.5.3 RetrospectiveIn comparison with the previous sprints, this sprint has been the least effective if comparing

the story points completed. The main problem was due to incomplete functionality with thebionic device prototype that the back-end team has been focusing on.

Unfortunate events / improvement needed• Egill’s computer operating system crashed and a whole workday went into restoring his

computer.

• The team decided to upgrade to Visual Studio 2017, which was time consuming due toconfigurations.

• Jón had to work a night shift the night before March 15th so he left early that day.

• More unit tests are needed.

Other events• Short meetings were held with the project owner each workday.

• Meeting was held with the team supervisor on March 11th.

• Team received a real bionic device prototype.

• Second status meeting took place on March 14th.

• At the end of the sprint, user stories 17-C, 18-C, 19-C and 20-C were canceled as theproject owner requested the team to focus on WiFi connectivity to the devices. The bulkof the functionality in the canceled stories would be implemented in the Bionics CommonPCL package. As that is not ready, implementing it in the application is not possible.


7.5.4 Timesheet




Egill Anton 39.75 248

Jón Söring 54.75 199.1

Skúli Þór 50.75 220.75

Total 183 863.35




7.6 Sprint 5 (March 18th - March 31st)

7.6.1 ThemeThe team updated previous stories because of new improvements in Bionics Common PCL.

The team also focused on completing the cloud sync functionality.

7.6.2 SummaryThe team completed the user story 10-A and started working on 11-A. Some improvements

were made to stories 3-A and 6-A from previous sprints. Besides working on the stories, theteam dealt with problems regarding connections with the bionic device prototype.

7.6.3 RetrospectiveThis is the first time the team felt falling a bit behind schedule. The main reason was due

to some rather complicated issues when trying to communicate with the device prototype theteam had borrowed in the previous sprint.

Considerable time was spent on debugging the application when the peripheral was at fault.The peripheral in question is a development prototype but the errors manifested in a way thatthe application looked to be at fault. Frequent visits to R&D specialists to correct the issueresulted in better functioning unit.

Changes on the Bionics Common PCL library required a lot of work to implement, but werenecessary to get access to reports and actions from the device. Because of these setbacks, thesprint backlog was not completed. The remaining tasks were moved to the following sprint.

Unfortunate events / improvement needed• Key issues with bionic device. Many hours spent into bug fixing the application when the

device was at fault.

• Changes made to the Bionics Common PCL library caused issues with existing code inthe application so a lot of code had to be redone.

• Benedikt Valur was absent during the second half of the sprint due to final exam prepara-tion.

Other events• Short meetings with the project owner were held each workday.

• Meeting with the team supervisor was held on March 29th.

• A new user story was added to the product backlog: 12-B - View and initiate actions (13story points).

• A new user story was added to the product backlog: 16-C - Run application on Androiddevice (3 story points).


7.6.4 Timesheet




Egill Anton 24 272


Skúli Þór 36 256.75

Total 114 977.35




7.7 Sprint 6 (April 1st - April 14th)

7.7.1 ThemeThe focus of this sprint is to finish all unfinished tasks from previous sprints and also work-

ing on creating the UI view for displaying peripheral actions and functionality for exporting thedata to CSV files.

7.7.2 SummaryThe team completed user stories 11-A and 12-B and worked finishing what was left from

user stories 3-A, 6-A and 9-A. The sprint went very well and all tasks were completed.

7.7.3 RetrospectiveAt the start of the sprint, the team finished establishing stable communications with the de-

vice prototype. This led to full focus on the new user stories.

The exam period at Reykjavik University started as expected. Benedikt could manage hiswork effort but Egill only joined the team for one day during the sprint.

Even though the team was mostly missing a member throughout the sprint, it managed tocomplete all tasks on April 12th. That gave the team the opportunity to start working on imple-menting functionality for displaying events for a specific peripheral.

Unfortunate events / improvement needed• The project owner was absent the later week.

• No meeting was held with the team supervisor due to his traveling abroad.

Other events• Easter holidays from April 13th - 17th.


7.7.4 Timesheet




Egill Anton 12 284

Jón Söring 39.2 279.3

Skúli Þór 31.3 288

Total 116.4 1093.8




7.8 Sprint 7 (April 15th - April 28th)

7.8.1 ThemeFor this second last sprint in this project the team focused on finishing the physical product

as much as possible before starting on other documents such as user manual and final report.

7.8.2 SummaryThe team completed user stories 13-B, 14-C, 15-C and 16-C. The main focus was on dis-

playing events for the specific device and plotting variables over time. The team also focused onfixing bugs that had been discovered in the application and work on more consistency betweenthe UI views.

7.8.3 RetrospectiveThe sprint went well and no problems were encountered. The team had a meeting with

the project owner which went well and he was very satisfied with the work so far. The onlything that he felt missing was more consistency between the UI views and he wanted to seethe application running on Android, which the team managed to complete before the end of thesprint.

Unfortunate events / improvement needed• Both Egill and Jón were absent on April 28th.

• Skúli and Benedikt attended the meeting on April 28th, but left early.

• The project owner was absent on April 17th - 21st.

Other events• Short meetings with the project owner were held on April 24th and 26th.

• Meeting with the team supervisor was held on April 26th.

• Benedikt and Egill both finished their final exams.

• Easter holidays from April 13th - 17th.


7.8.4 Timesheet



Benni 46.5 289

Egill 52.5 336.5

Söring 30 309.27

Skúli 48 336

Total 177 1270.77




7.9 Sprint 8 (April 29th - May 13th)

7.9.1 ThemeFor this final sprint, the team focused on finishing all documentation and preparation for the

final hand-in of the project and the third status meeting.

7.9.2 SummaryThe team finished the final report, the user manual, the operating manual and all remaining

code documentation. All functions, member variables, and XAML views were commented.The team also created a static HTML documentation file that is located in the Help directoryunder the project folder.

More unit tests were added and system tests were performed on the Android and the UWPversion. A simple user test was also performed by an R&D specialist. The number of workedhours for each team member was more than twice that of a normal sprint!

7.9.3 RetrospectiveThe team was organized and worked well the whole sprint. All team members participated

in finishing all remaining work. The team finished these documents on May 11th.

The third status meeting was held with the teacher, supervisor and examiner on May 8th. Theteam got feedback from the meeting and used their comments to improve upon the presentationand final report. The team used the next following days to prepare for the final presentationwhich was on May 16th.

Unfortunate events / improvement needed• Considerably more time took to finish all documents than expected.

Other events• Short meetings were held with the project owner each workday.

• User tests were performed by an R&D specialist.

• Meeting was held with the team supervisor April 29th.


7.9.4 Timesheet



Benni 96.5 385.5

Egill 96.75 433.25

Söring 89.73 399

Skúli 87.75 423.75

Total 370.73 1641.5



42

Chapter 8Project Summary

8.1 Project BurndownFigure 8.1 shows the progress made during the development process. The figure reflects the

information found in the product backlog (Table 3.2). After the first sprint, the team maintaineda steady pace of burning down story points. Between sprint 4 and 5, the team decided to cancelfour stories, resulting in a drop of 36 story points. Between sprint 5 and 6, two new stories wereadded to the backlog, adding 16 story points. The team was able to burn all the story pointsbefore starting sprint 8.

Figure 8.1: Actual project burndown chard

8.2 Work Time OverviewThe team put in a total of 1641.5 hours of work during the course of the project (Table 8.1).

This exceeded the initial estimate by 28%. Finding the reason for this overrun a closer lookhas to be taken at the time spent on the different categories the project was split into. Twoestimates were made in the organization of the project (Chapter 2.2), that was the time spenton development and time spent administration and writing reports. Looking at the developmenttime of TÝR, the group exceeded the estimate by 14% due to the fact that the group was ableand willing to spend more time on application development over the course of the project.While time spent on administration and, most significantly, the reports and hand-ins exceededestimates by 69%. A large portion of this time was logged during the final sprint (no. 8) and isattributed to the third status report and hand-in of the final report and associated documents.

CHAPTER 8. PROJECT SUMMARY 43

Table 8.1: Project - Time estimates vs actual values

Categories Planned (Hours) Actual (Hours) Difference

Whole project 1280 1641.5 28 %

Programming, Design, Analysis,Testing, Setup & Learning

950 1085 14 %

Admin, Meetings & Reports 330 556.6 69 %

Distribution of work between each of the categories can be seen in figure 8.2. It is worthnoting that the line between programming and designing are not very clearly defined in the timemanagement system implemented for this project. It is safe to say that a portion of the timeslabeled as programming should rather be categorized as design.

Figure 8.2: Percentage of time spent on categories

Time contribution by team members as seen in table 8.2 shows the time spent by each groupmember. Time commitment varies slightly with the highest contributing member having 10%more time logged than the member with the fewest times. Figure 8.3 breaks down the workedhours into five categories to better demonstrate what those hours were spent on.

Table 8.2: Project - Work overview

Team Member Total Work in Project (Hours) Ratio of total

Benedikt Valur 385.50 23.5 %

Egill Anton 433.25 26.4 %

Jón Söring 399.00 24.3 %

Skúli Þór 423.75 25.8 %

Total 1641.50

CHAPTER 8. PROJECT SUMMARY 44

Figure 8.3: Project work time overview

8.3 Project RetrospectiveThe team has managed to deliver a functioning cross-platform application that runs on UWP,

iOS and Android. The application has all required functionalities and is ready for Össur tocontinue its development.

Most important in any project is collaboration. The team members worked well together andmaintained an enjoyable working experience over the course of the project. Each team mem-ber worked hard and contributed greatly to the project. The team maintained a steady workingpace from start to finish due to good management and planning set forth at the beginning of theproject. The team was regularly able to meet with its supervisor and get valuable informationand advice on presenting and setting up the project work.

The team required some time to get over the rather steep learning curve of the Xam-arin.Forms framework. By the end of the project, the team had a fairly good understandingof its features and limits. The team also got valuable experience using Visual Studio to manage,build and deploy complicated multi-project, cross-platform solutions.

The project owner was clear on the project requirements and willing to take suggestionsfrom the group. The access to the project owner was great and he was able to provide for theteam a great working environment in Össur and bionic device prototypes for trying out the appli-cation during development. Over the course of the project, some technical issues came up whenworking with the prototypes but the team managed to overcome them. Sometimes Bionics Com-mon PCL library also had a large part in those technical issues, as it was also in developmentover the project period. Therefore, it didn’t always function as expected. In general, the teamwas very happy with the project and how the original idea turned into a useful software solution.

45

Chapter 9Conclusion

9.1 Future ImprovementsAs the user test confirmed, some things can be improved in the UWP user interface to

increase its usability. Especially, the flow between different pages can be simplified and feed-back to the user increased. Delivering an iOS packaged version of the application may also bean important goal soon and should not require a lot of additional work.

As development of the Bionics Common PCL code continues, TÝR will need to be updatedto reflect the capabilities and communication methods made available in time. For example, ifconnectivity of the prosthetic devices will be increased to a degree where direct connections tothe Bionic Cloud were possible, it would open many new possibilities for TÝR to potentiallymanage cloud-connected devices.

Other future possibilities include adding improved plotting and analysis tool into TÝR toallow for immediate analysis of data. Finally, adding a user tutorial to the application itselfcould be beneficial for inexperienced users.

9.2 ConclusionThe development of TÝR was a success. The team fulfilled all the major goals required for

the user interface to work correctly and managed to connect the application to other complicatedsystems from Össur, especially to new bionic device prototypes and the Bionic Cloud service.The application has many possibilities for future development and can become an importantpart in future device development at Össur.

The team would like to thank the project owner, Kristján Þór Finnson, for all his help. Hewas always willing to give feedback and provide assistance when needed. The team would alsolike to thank supervisor, Torfi Helgi Leifsson, for all his help and guidance regarding the projectsetup and presentation. The team also wants to thank all the other specialists that gave their timeto help the team over the project period.

46

Appendix AAppendix

A.1 Terms and DefinitionsAMQP

Advanced Message Queuing Protocol (AMQP). A light-weight communication protocolsimilar to TCP/IP, mostly known for being the preferred protocol in Internet of things (IoT).

APIApplication programming interface. Describes services available through the specified API.

REST API is an API implementation that communicates through HTTP calls using one or allof the HTTP verbs GET, POST, PUT, PATCH or DELETE.

BLEBluetooth low energy (BLE).

MVVM"Model–view–viewmodel" software architectural pattern.

R&DResearch and development (R&D).

SQLite3A cross-platform SQL database engine.

TÝRThe production name for the cross-platform client application of this project. The name has

still not been officially accepted by Össur and might change in the future.

UWPUniversal Windows Platform, an application platform for Windows 10.

Visual StudioThe development environment used to program the application.

Xamarin.FormsA cross-platform framework that allows developers to create cross-platform applications.

Össur Bionic CloudA cloud service created by Össur to collect and store data remotely from bionic devices.

The service provides a simple API for posting and receiving data to/from the cloud service.

Össur Bionics Common PCLSoftware library created by Össur to facilitate communications with bionic devices. Defines

the communication standard used to communicate with the devices and includes classes thatallow for easier interfacing with the devices.

APPENDIX A. APPENDIX 47

A.2 System Tests

A.2.1 UWP - Windows 10The following tests were performed on the UWP application running on Windows 10 oper-

ating system. The tables below describe what functionality was tested each time, the expectedresults from that test and the actual results. An actual bionic device prototype was used for thetests. The minor bugs discovered regarding values of variables were fixed soon after testing.

1. User logs in:

Table A.1: User authentication

No Description Expected behavior Actual behavior Error Tested

1 User logs in withcorrect user nameand password

Login successfull. Usertaken to Home page.

As expected No Benedikt25/04/2017

2 User logs in withincorrect username andpassword

Login should fail.Error messagedisplayed.


2. After user logs in:

Table A.2: User logged in


3 Initial page Home page. Userinformation should bedisplayed. In the leftsidebar, four buttonsshould be visible;Home, Devices, About,and Logout


4 Click Aboutbutton on leftsidebar

User is taken to Aboutpage


5 Click Homebutton on leftsidebar

User is taken to Homepage


6 Click Devicesbutton on leftsidebar

User is taken toDevices Page, whichshould not display anydevices.



3. User has clicked the Device button on the left sidebar (No. 6):

Table A.3: Device list page


7 Click Scan ForDevices button

List of availabledevices should appear.


8 Click Connectbutton for anavailable devicein the list.

The Connect buttonchanges to Manage.Selected deviceappears in left sidebarwith buttons Manageand Disconnect.


9 Click Disconnectfor the connecteddevice in the leftsidebar

Device is removedfrom left sidebar andthe Manage button inthe main view changesback to Connect.


10 Select Connectand then Managefrom main page.

User is taken to thatdevice’s home page

As expected No Benedikt,26/04/2017

11 Select Connectand Managefrom sidebar

User is taken to thatdevice’s home page.


12 Search for adevice in thesearch bar thatdoes exist

Devices that matchsearch parameters aredisplayed in a listunder the search bar.


13 Search for adevice in thesearch bar thatdoes not exist

Empty list is displayedas search parametersdidn’t match anyexisting devices.



4. User has connected to an available device from the device list and chosen Manage (No.10 - 11):

Table A.4: Device home page


14 Click Variables List of availablevariables displayed.


15 Click Actions List of availableactions displayed.


16 Click Reports List of available reporttypes displayed.


17 Click Events List of previous eventsdisplayed.


18 Click Deviceinformation

Information about thedevice displayed.


19 Click Disconnectfor the connecteddevice on the leftsidebar

User is taken back tothe device list page,showing all availabledevices. The deviceshould now bedisconnected andremoved from the leftsidebar.



5. User has connected to a device and chosen the Variables button (No. 14):

Table A.5: Variables page


20 Search for “gain”variable and clickthe configurebutton

A view for configuringthe value of thevariable, along with atime graph, displayed.


21 Change value to anumber between1 and 32767, andclick Save.

The new value is savedto the local databaseand a new pointappears on the graph,showing the value andthe time of change.


22 Change value to anegative number,and click Save.

Value is set to zero. Value is saved asthe negativenumber in thedatabase.

Yes* Benedikt26/04/2017

23 Change the valueto a numbergreater than32767 (themaximum value)and click Save.

The new value doesn’texceed max value.


24 Add enoughnumbers to valueso it becomesbigger thanmaximum value

The new value doesn’texceed max value.

Value is saved todatabase aschosen,regardless of maxvalue.

Yes* Benedikt26/04/2017

*The problems discovered in tests nr. 22 and 24 in table A.5 were fixed the same day. Now,the new variable value can’t be less than the minimum value or higher than maximum valuegiven for that variable type. Both the minimum and maximum values are visible on the page.


6. User has connected to a device and chosen the Actions button (No. 15):

Table A.6: Actions page


25 Change heelheight andexecute action

The heel changes itsheight according tochosen values.

As expected No Skúli,30/04/2017

26 Click the Eventsbutton for thedevice

Two new events for thepreviously executedaction (Action-Started/ActionDone)should appear in theevents list with theirtimestamps.

As expected No Skúli30/04/2017


7. User has connected to a device and chosen the Reports button (No. 16):

Table A.7: Reports page


27 Click LogReports settingsbutton

A list of all previouslycreated log reports forthe device should bedisplayed.


28 Click Create anew report button

A new log reportshould be added to thelist, with a timestamp,the model name of thedevice and the serialnumber.


29 Click the viewbutton for thenewly created logreport

A new page shouldopen, showing alldetails from the newlycreated report.


30 Go back andclick Create anew report again

A new log reportshould be added to thelist with a newtimestamp, differentfrom the older reports.


31 Go back, clickStep HistogramReports and thenclick Create anew report button

A new step histogramreport should be addedto the list, with atimestamp, the modelname of the device andthe serial number.


32 Go back andsearch for a“histogram” inthe search box

All report types whichhave a “histogram” intheir description shouldbe listed.


33 Choose StepHistogramReports settingsbutton.

The newly createdreport should be listedthere.


34 Go back andclick Eventsbutton

For all the newlycreated reports, twoevents have beencreated and added tothe events list (Report-Started/ReportDone).



8. User has connected to a device and chosen the Device Information button (No. 18):

Table A.8: Device Information page


35 Turn Auto-Syncswitch to On. Goto Variables andchange any“gain” value andclick Save.

The new “gain” valueshould been sent tocloud within 10seconds.


36 In DeviceInformation, turnAuto-Sync offand repeat taskNo. 35 again.

The new “gain” valueshould not be sent tothe cloud.


37 In DeviceInformation,click Sync toCloud button.

Now the new “gain”value should be sent tothe cloud.


38 Turn Auto-Syncon, then clickDisconnect Inleft sidebar. Now,click Connect forthe same device.

The Auto-Sync switchshould be turned off ondefault.


39 Click the ExportCSV button

In the Downloadsfolder, a folder namedTýr should appear.Inside, there should betwo new .csv-files, onefor all variables(“tyr_variables_xxx.csv")and other for all events(“tyr_events_xxx.csv")exported from the localdatabase.


40 Click Logoutwithout clickingDisconnect forthe device. Now,log in again.

No device should befound on the leftsidebar.



A.2.2 Android app - ASUSThe following tests were performed on the Android application running on ASUS Zenpad

C 7.0. The tables below describe what aspect was tested each time, the expected results fromthe test and the actual results. A "dummy" peripheral from the Össur Common PCL library wasused for the testing instead of an actual bionic device.

1. User logs in on Android:

Table A.9: User logged in on Android


1 Login withcorrect user andpassword

Login successfull. Usertaken to Home screen


2 Login withincorrect userand password

Login should fail.Display error message


2. After user logs in on Android:

Table A.10: User logged in on Android


3 Starting state User name and user IDshould be displayed. Inthe left sidebar thereshould be four buttons;Home, Devices, About,and Logout


4 Click Aboutbutton on leftmenu

User is taken to Aboutpage


5 Click Homebutton on leftmenu

User is taken to Homepage

As expected No Skúli,04/05/2017

6 Click Devicesbutton on leftmenu

User is taken toDevices view/page,which should not showany devices.



3. User has clicked the Device button on the left sidebar, on Android (No. 6):

Table A.11: Device list page on Android


7 Click Scan ForDevices

List of availabledevices should appear.


8 Click Connectbutton for anavailable devicein the list.

The Connect buttonchanges to Manage.Selected deviceappears in left sidebarwith buttons Manageand Disconnect.


9 Click Disconnectin the left sidebarfor the connecteddevice

Device is removedfrom left sidebar andthe Manage button inthe main page changesback to Connect.


10 Select Connectand then Managefrom main view.

User is taken to thatdevice’s homepage/view


11 Select Connectand Managefrom sidebar

User is taken to thatdevice’s homepage/view.


12 Search for adevice that doesexists in thesearch bar

Devices that matchsearch parameters aredisplayed in a listunder the search bar.


13 Search for adevice in thesearch bar thatdoes not exists

Empty list is displayedas search parametersdidn’t match anyexisting devices.



4. User has connected to an available device from the device list and chosen Manage, onAndroid (No. 10 - 11):

Table A.12: Device home page on Android


14 Click Variables Display list of availablevariables.


15 Click Actions Display list of availableactions.


16 Click Reports Display list of availablereport types.


17 Click Events Display list of previousevents.


18 Click Deviceinformation

Display informationabout device.


19 Click Disconnectfor the connecteddevice on the leftsidebar

User is taken back tothe device list page,showing all availabledevices. The deviceshould now bedisconnected andremoved from the leftsidebar.



5. User has connected to a device and chosen the Variables button, on Android (No. 14):

Table A.13: Variables page on Android


20 Search for “gain”variable and clickthe configurebutton

Display view forconfiguring the valueof the variable.


21 Change value to anumber between1 and 32767, andclick Save.

Value is saved The slider worksfine but changingthe value in thetextbox doesn’twork correctly.

No Skúli04/05/2017

22 Change value to anegative number,and click Save.

Value is set to zero. As expected No Skúli04/05/2017

23 Change the valueto a numbergreater than32767 (themaximum value)and click Save.

Value is set tomaximum value.


24 Add enoughzeros to value soit becomes biggerthan maximumvalue

Value is set tomaximum value.



6. User has connected to a device and chosen the Actions button, on Android (No. 15):

Table A.14: Actions page, on Android


25 Change heelheight andexecute action

The heel changes itsheight according tochosen values.

N/A (notconnected to areal device)

N/A Skúli04/05/2017

26 Click the Eventsbutton for thedevice

Two new events for thepreviously executedaction (Action-Started/ActionDone)should appear in theevents list with theirtimestamps.



7. User has connected to a device and chosen the Reports button, on Android (No. 16):

Table A.15: Reports page on Android


27 Click LogReports settingsbutton

A list of all previouslycreated log reports forthe device should bedisplayed.


28 Click Create anew report button

A new log reportshould be added to thelist, with a timestamp,the model name of thedevice and the serialnumber.


29 Click the viewbutton for thenewly created logreport

A new page shouldopen, showing alldetails from the newlycreated report.


30 Go back andclick Create anew report again

A new log reportshould be added to thelist with a newtimestamp, differentfrom the older reports.


31 Go back, clickStep HistogramReports and thenclick Create anew report button

A new step histogramreport should be addedto the list, with atimestamp, the modelname of the device andthe serial number.


32 Go back andsearch for a“histogram” inthe search box

All report types whichhave a “histogram” intheir description shouldbe listed.


33 Choose StepHistogramReports settingsbutton.

The newly createdreport should be listedthere.


34 Go back andclick Eventsbutton

For all the newlycreated reports, twoevents have beencreated and added tothe events list (Report-Started/ReportDone).



8. User has connected to a device and chosen the Device Information button, on Android(No. 18):

Table A.16: Device Information page on Android


35 Turn Auto-Syncswitch to On. Goto Variables andchange any“gain” value andclick Save.

The new “gain” valueshould been sent tocloud.


36 In DeviceInformation, turnAuto-Sync offand repeat tasknr. 35 again.

The new “gain” valueshould not have beensent to the cloud.


37 In DeviceInformation,push Sync toCloud button.

Now the new “gain”value should be sent tothe cloud.


38 Turn Auto-Syncon, then clickDisconnect Inleft sidebar. Now,click Connect forthe same device.

The Auto-Sync switchshould be turned off bydefault.


39 Click the ExportCSV button

In the root folder, afolder named TYRshould appear. Inside,there should be twonew files, one for allvariables(“tyr_variables_xxx.csv")and other for all events(“tyr_events_xxx.csv")from the localdatabase.


40 Click Logoutwithout clickingDisconnect forthe device. Now,log in again.

No devices should befound on the leftsidebar.


School of Computer ScienceReykjavík UniversityMenntavegur 1101 Reykjavík, IcelandTel. +354 599 6200Fax +354 599 6201www.ru.is

www.ru.is