Agile development model for certifiable medical device software

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Agile development model for certifiable

medical device software

Erica E. F. Lima

Mestrado em Engenharia de Software Supervisor: Professor Doctor Gil Gonçalves

(2)

(3)

Agile development model for certifiable medical device

software

Erica E. F. Lima

Mestrado em Engenharia de Software

(4)

(5)

Abstract

This study aims to illustrate the current status when the subject is medical device software using agile. Introduces the needs of the regulation and the standards to be a certifiable medical device software and how this is the safer and quality way to do it.

The problem that many companies feel obligated to use the waterfall still when it is a project too complex or have many regulations as the only way to build software. The medical area is not different; it is challenging to put agile and still comply with all regulations and standards.

This dissertation illustrates efforts that others have already done using agile and try to find the best way to proceed by validation, through an academic case and interviews and finally contribute with a final proposed process.

Keywords: Agile development, Agile methodologies, Medical device, Scrum, Process, Reg-ulation, Software life cycle processes, Risk Management, Software Process Improvement (SPI), FDA, Medical device industry.

(6)

(7)

Resumo

Este estudo tem como objetivo ilustrar como está o estado atual quando o assunto é software de dispositivo médico utilizando agile. Apresenta as necessidades dos regulamentos e padrões para ser um software de dispositivo médico certificável e como essa é a maneira mais segura e de qualidade de fazê-lo.

O problema que muitas empresas se sentem obrigadas a usar a cachoeira ainda quando é um projeto muito complexo ou tem muitas regulamentações como única forma de construir software. A área médica não é diferente; é um desafio ser ágil e ainda cumprir todos os regulamentos e padrões.

Este artigo irá ilustrar alguns trabalhos que outros já fizeram utilizando agile e tentar encontrar a melhor forma de proceder por validação, através de um caso acadêmico e entrevistas e finalmente contribuir com uma proposta de processo final.

Keywords: Desenvolvimento Ágil, Metodologias Ágeis, Dispositivos médicos, Scrum, Processo, Regulamentação, Processos do ciclo de vida de software, Gerenciamento de riscos, Melhoria de processos de software (SPI), FDA, Indústria de dispositivos médicos.

(8)

(9)

Acknowledgements

I dedicate my first thanks to my advisor, Gil Gonçalves, whose experience was invaluable in for-mulating research and methodology questions. He supported me with the topic from the beginning and helped me have discipline and guidance to finish the thesis.

I thank all the Master’s professors of FEUP, who made me learn even more and made me a better professional.

I also thank Samira Tavares, Analia Irigoyen, and Carlos Rodriguez. They helped me with meaningful advice and feedback that improve my final process by participating in the validation interview. I also want to thank all academic case team members who welcomed me as a team member and helped me with this research.

In addition, I would like to thank my parents and hope that they are proud of me once again with this study. I’m also grateful to my fiancé, João Miranda, whom I thank for choosing to embark with me on this new adventure that was the Masters, and also for all the help to stay focused to finalize this thesis. Finally, thanks to all my family and friends, who have always supported me and my choices.

Erica Lima

(10)

(11)

“Continuous improvement is not about the things you do well -that’s work. Continuous improvement is about removing the things that get in the way of your work. The headaches, the things that slow you down, tha’s what continuous improvement is all about. ”

Bruce Hamilton

(12)

(13)

5.1.1 Academic Validation . . . 35 5.2 Process Validation . . . 37 5.2.1 Results . . . 38 5.2.2 Adaptions . . . 40 5.3 Conclusion . . . 41 6 Interviews 43 6.1 Validation Interviews . . . 43 6.1.1 Samira’s Interview . . . 44 6.1.2 Analia’s Interview . . . 46 6.1.3 Carlos’s Interview . . . 49 6.2 Conclusion . . . 50 7 Solution 53 7.1 Problem . . . 53 7.2 Contribution . . . 53 7.2.1 GDPR . . . 54 7.2.2 Usability . . . 54 7.2.3 Risk Management . . . 56 7.2.4 DevOps . . . 57 7.2.5 Non-Conformance Report . . . 58 7.3 Solution . . . 59 7.3.1 Product Discovery . . . 59 7.3.2 Product Delivery . . . 60 7.3.3 Improvements . . . 61

8 Conclusions and Future Work 63 8.1 Conclusions . . . 63

8.2 Future Work . . . 65

References 67 A Metrics Hive Health 71 B Interview Script 75 B.1 Script Plan . . . 75 B.1.1 Introductory Questions . . . 75 B.1.2 Process Questions . . . 75 B.1.3 Validation Questions . . . 76 C Fast sheet 77

(15)

List of Figures

2.1 Software development processes and activities [37] . . . 8

2.2 Definitions for probability and severity [31] . . . 10

3.1 Life cycle XP process. [6] . . . 16

3.2 TDD principles [34] . . . 17

3.3 Configuration Management and Planning [10] . . . 19

3.4 Relationships between validation, verification and testing [40] . . . 20

3.5 Design controls, verification and validation [40] . . . 21

3.6 V-model [11] . . . 23

3.7 Cochlear’s Design Control Process for software [33] . . . 24

3.8 MDevSPICE processes [R 28] . . . 25

3.9 Paper screening process [28] . . . 26

3.10 AV-Model process. [26] . . . 27

4.1 Scrum for medical devices [42] . . . 29

4.2 Validation process . . . 33

5.1 Product Development Plan [18] . . . 37

5.2 My Health Diary - App and Web Application [18] . . . 39

6.1 Process First version . . . 46

6.2 Process Second version . . . 47

7.1 Human factors affect outcomes of using medical devices [27] . . . 55

7.2 Summary of the most observable clauses in the standards with DevOps [24] . . . 58

7.3 Non-Conformance Rerport . . . 59

7.4 Final Process proposed. . . 61

A.1 Sprint 1 [18] . . . 71

A.2 Sprint 2[18] . . . 72

A.3 Sprint 3 [18] . . . 72

A.4 Sprint 4 [18] . . . 73

A.5 Integration Sprint 1 [18] . . . 73

A.6 Integration Sprint 2 [18] . . . 73

(16)

(17)

List of Tables

2.1 Classification of medical devices [21] . . . 6

3.1 Advantages and disadvantages of several SDLC’s . . . 22

5.1 Metrics PMIE Case . . . 40

5.2 Adaptations to the process . . . 40

6.1 Interviewee profiles . . . 44

(18)

(19)

Abbreviations

AIMDD Active Implantable Medical Device Directive BDD Behavior Driven Development

DSDM Dynamic systems development method GDPR General Data Protection Regulation IVD In-vitro Diagnostic

MDD Medical Device Directive

PMIE Project Management, Innovation and Entrepreneurship PO Product Owner

SDLC Software Development Life Cycle SM Scrum Master

TDD Test-driven development WWW World Wide Web

XP Extreme programming

(20)

(21)

Chapter 1

Introduction

This thesis addresses Software in the Medical Device field. This chapter has the context, motiva-tion, and document structure.

1.1 Context

There are many professions that can put the life of a person in danger with one mistake. Our world is now becoming more technological, there are systems and mobile applications for almost anything. There are no major issues when it is only a game, but when it is about health or assisting doctors it is a different picture. That is why there are so many regulations required in this new scenario where software is made for medical applications. This thesis is a study in the application of agile methods in the development of software for medical devices, to help developers building products with quality and updates that are compliant with the regulations.

"Promoting good health is an integral part of the smart and inclusive growth objec-tives for Europe 2020. Keeping people healthy and active for longer has a positive impact on productivity and competitiveness. Innovation in healthcare helps take up the challenge of sustainability in the sector in the context of demographic change" [17]

The software itself is always evolving, and because of that, the legislation had to be updated in 2017 to keep the software in the medical area safer, secure, and with standard quality. The change involves putting more accountability in authorities, economy agents, notified bodies, and health professionals. The importance of having these standards and regulations in medical device software is to guarantee better processes and better quality medical device software. Depending on the region there are different standards, regulations, and guidance. For the USA is the Food and Drug Administration (FDA) and for the EU is the Medical Device Directive (MDD) 93/42/EEC, the Active Implantable Medical Device Directive (AIMDD) 90/385/EEC, and the In-vitro Diag-nostic (IVD) Medical Device Directive 98/79/EC —all three of which have been amended by 2007/47/EC. [28]

(22)

2 Introduction

There is no magic; it is a lot of work to build a software development life cycle (SDLC) that could help to build the software with all the compliance equality needed. And even then, there are a lot of risks and failures that could happen in the process. It’s not easy to do software properly, but having an SDLC is not only required by standards but also greatly facilitates product management and tracking. Choosing the right one for the software is challenging and will be discussed in this study.

Agile has been adopted by companies around the world, especially software companies. This adoption is because they get feedback to improve the software quicker and get better results with the users when delivering continuously. By doing so, the software is more flexible to changes in all phases, which is a better way, since the users are humans and change their mind with time and with knowledge of the software tends to change functionalities that will improve the quality and the value to the user. Furthermore, agile is only a mindset; there are many frameworks and techniques to help build the product. This paper will be analyzed Scrum, DSDM, XP, TDD, and BDD itself and how this can be used in the medical device field. Another scenario that it should be a concern in software in general, but in a medical device in particular because of the risk, is usability. Depending on who is going to use must the software, we should think about how the software will guide the user to make as little mistakes as possible. There are reports of accidents because of failure in the design of the software, and when the layout can cause wrong results and even be fatal if the software is misused.

This research’s validation process will be to use the final process created in the previous work to validate in an academic case. After that, the first updated version of the process will be prepared and discussed with an one agile expert. After that, following the idea of continuous improvement, another updated version will be developed and validated with two other agile experts, and finally, as a result, the final process after these steps validation and improvement steps were taken.

1.2 Motivation

Every project can be developed by using an agile methodology, and this methodology is growing in popularity. In the 14th annual state of the agile report says that more than 95% of respondents report their organizations to practice agile development methods. [22] organizations now follow-ing an agile approach in 2020. Even those which are regulated or especially those. It is a need in every project to continuous improvement and learns fast so that it can avoid the same risk or mistake again. When people think about doing software is not just programming at all. There are a lot of processes to ensure quality that if the project follows, it will generate a large amount of value for everyone. Especially when it is a software that could cost a life must have more re-liability. Because of that, the methodology that is more used nowadays is waterfall, which is a methodology already used for longer and in the comfort zone of companies. But if companies stay in their comfort zone the improvement in their processes will be difficult.

Due to the challenge to do a process that includes the benefits of agile and the guarantee of the regulations altogether, this study aims to demonstrate a thorough study between these areas

(23)

1.3 Document Structure 3

and proposals already made to solve the challenge by illustrating the process that needs to be done to be compliant with the regulations and standards without harm the usability, quality, and effort of the software and developers. Furthermore, this study will propose a process not only with the medical regulations in mind but also with the compliance with General Data Protection Regulation (GDPR).

1.3 Document Structure

Below is a brief explanation of each chapter in this document:

The first chapter is the introduction of the thesis, the context, motivation, and the structure of the document.

In the second and third chapters are state of the art and the research made by this study. Divide by regulation, process, and methodologies.

In the fourth section the starting point for this study is presented, together with a set of im-provement opportunities.

The fifth paragraph presents the initial solution where the context of the problem is explained, along side the contributions and the solution. It also includes the presentation of the validation plan for the process.

In the sixth paragraph is the validation of the process using an academic case. Which is detailed the process, how was done, the adaptations made, and the results.

The seventh paragraph is the validation interviews made with agile experts to receive feedback about the process made. This chapter has the three interviews detailed and the new process created by the review of the interviewees.

In the eighth paragraph and the last one are presented the conclusions and future work of this thesis.

(24)

(25)

Chapter 2

State of the art - Regulation

There was a radical change in Europe in the subject of medical devices with the publication the directive 2007/47/EC [38] by the European Council in 2007 after which software was considered to be a medical device. After this, the more recent directive was the 2017/45/EEC [15] which is an update consolidating software as medical devices in the industry. [41]

Software is considered an active device by the regulation 2017/45/EEC, so every consideration about an active device should be respected for software. [15]

From the user or patient perspective, it is clear that it must have standards to assure the safety of the product. This helps in the confidence that the product works. If we think about the context of 2020, the development of a vaccine for COVID-19 requires many phases to assure that the vaccine is safe and can be taken by everyone. In our universe of medical devices, any equipment or devices used in health care also needs to meet a high level of safety standards. [30]

2.1 Medical Devices Regulation in EU

Regulations are the instruments that governing bodies use to assure the safety and efficacy of medical devices.[12] But most importantly, as it is mandatory for the company to follow the rules to enter the market with the certificate in medical device software, it ensures the minimum of safety for the users and standard between others. In 1993 the European Council released the Medical Device Directive (MDD) so that it could ensure the safety of medical devices placed on the European market. [32]

When it is about the regulation, even being MDD or FDA, the challenge to development re-mains the same. There are some in the list below [28]:

• Adherence to many regulatory requirements specified in various international standards; • Establishing a full traceability schema from stakeholder requirements to code;

• Performing changes to process artifacts (requirements, code, documents) in a traceable way; • Being able to embrace change during development;

• Producing development evidence for auditory purposes consistently and continuously and managing the documentation process in an effective way so that it is not overwhelming;

(26)

6 State of the art - Regulation

Table 2.1: Classification of medical devices [21] Risk Classes Risk level

Class I Low risk Class IIa Medium risk Class IIb Medium risk Class III High risk

• Ensuring reliability, safety, and correctness of products; • Improving the quality of products and productivity of teams;

• The necessity of clinical software validation to be done manually in some cases.

These are all problems that persist, and this paper will try to illustrate the situation and possible solutions for them.

2.2 Medical Device

First, a medical device is any instrument, apparatus, appliance, software, material, or another ar-ticle, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of diagno-sis, prevention, monitoring, treatment or alleviation of disease, diagnodiagno-sis, monitoring, treatment, alleviation of or compensation for an injury or handicap, Investigation, replacement or modifi-cation of the anatomy or of a physiological process, Control of conception, and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means. [21].

So, the main concern is the people that are going to use these medical devices. Software for other areas there isn’t so much risk as to the medicine area because if a bug happens, its normal, but imagine a fatal bug in a real-life at stake. That’s why they came up with regulations only for medical devices, and it must always be updated cause technology is always changing. Even with this purpose in mind, it is natural to try to improve how to build these devices so it will cost less effort and still respect the regulation and the safety of the users. Because of that, the regulation has imposed a classification of medical devices.

This classification was calculated by taking into account the factors: [21]

• Length of time in contact with the human body (Transient, short-term, and long-term); • Degree of invasion of the human body (Invasive, non-invasive);

• Part of anatomy affected by its use (Brain, heart, lower limbs, etc.); • Potential risks stemming from technical design or manufacture

Depending on which classification the medical device is applied, there are rules and good practices to follow.

(27)

2.3 Software as medical device 7

The International Medical Device Regulators Forum (IMDRF) recommends using this IEC 62304: 2006 standard, as the cause provides a solution for compliance with relevant legislation requirements with European standards. [20]

This standard IEC 62304: 2006 has the security classification determined by these criteria[41]: • In the case of a product classified as Class A, there is no injury or damage to the health of

the user in the event of product failure;

• In the event that the safety classification is Class B, some type of injury may occur, but this is not serious and does not endanger the user’s life;

• If the classification is Class C, the software is considered to be high risk and may cause injury serious or even death of the actors.

There is some indirect correspondence criteria between these classifications, since the IEC 62304:2006 is only applied to software the comparasion would be that A Class classification would correspond to a Class III classification. To conclude, that classification of software security can never be higher than the security rating of the device. [16]

2.3 Software as medical device

For a software to be accepted as a medical device must be specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device. Software is also considered an active device that must have interoperability, which is the ability of two or more devices from the same manufacturer or from different manufactures to:

a. exchange information and use the information that has been exchanged for the correct execution of a specified function without changing the content of the data, and/or

b. communicate with each other, and/or c. work together as intended. [15]

Another concern for the regulation is the risks associates with the possible negative interaction between the software and the computing environment in which works and interacts.

The validation and verification of the software must have a summary of the results of all both at the level as in the user’s environment, simulated or actual, before the final release. [15]

As was informed before, there are a lot of points that need to do in the development of this software to be certified or at least be approved to go to the medical market. The presence of software in the medical area is undeniable. More than 50% of existing medical devices depend on the operation of software systems in any way. [41]

With that in mind, it is needed a process to help the life cycle of software development so that it would be possible to respect the regulation and also do the software in an agile way with lost of updates and still continuing to be certified to be in the market with the changes. This is the challenge, have the balance between the regulation and the process to keep the regulation even with the new releases.

(28)

2.4 Medical device standards

According to the International Organization for Standardization(ISO): “Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines or definitions of characteristics, to ensure that materials, products, process, and services are fit for their purpose.”

When the subject is the medical device, it would be strange to not have a standard or regulation to take care of, even more, when it is well known that software is not trustworthy in other fields, so when is about medical area one software failure can have catastrophic consequences. That’s why it is indispensable to have many standards and regulations about it.

One standard is the ANSI/AAMI/IEC 62304:2006 Standard, also title as “Medical Device Software-Software Life Cycle Processes,” [37] is an FDA recognized standard. In figure2.1 it is showed the activities and processes that the standard recommends, so it will be possible for the software to be compliant by it.

Figure 2.1: Software development processes and activities [37] .

This standard is the only one for the purpose of medical device software and is considered one critical standard for software developers cause the main processes that development should have:

(29)

2.4 Medical device standards 9

[42]

• The Development Process: The standard requires the creation of development planning, responsible for orchestrating process activities, and appropriate to the size and security rating of the system. The model used in the cycle should be detailed in the planning, which should also detail the deliverables of the traceability strategy between system requirements, software, testing, and risk management measures. Other recommended activities in the document are requirements analysis, architectural design, detailed design, implementation, integration, system testing, and delivery.

• The maintenance process: Although sometimes classified as an activity, the standard consid-ers maintenance as an independent process. The producer should develop maintenance planning where attention is given to the feedback the product receives after it is delivered. Strategies for receiving, documenting, evaluating, resolving, and monitoring this feedback.

• The risk management process: The producer should implement a risk management system and include it in the planning of the development process. Because of that, the ISO standard must be followed. 14971: 2007 and IEC / TR 80002-1: 2009 (which guides the implementation of the previous in the context of the software)

• The Configuration Management Process: Must Be Included in Development Planning con-figuration management information. This includes all tasks and actions in this area, a list of items to be checked, versioning, and traceability of all changes each item.

• The problem-solving process: The standard forces the producer to create a report for each problem identified in the product, which must include a type, scope, and criticality. Besides that, strategies should be prepared to investigate and solve the problem, as well as to maintain their traceability. Finally, testing activities should be created, and documentation updated when prob-lems are encountered.

2.4.1 Traceability

Traceability is one requirement that the standard IEC 62304 demand and came with the need to target the safety in medical device software. It is common to use traceability when it is to link a requirement with a test case. It is a way to organize even more the project and the life cycle and follows every phase the artifact that the traceability came from or going to. Now the traceability has evolved to more than just using in the requirements but also in areas like defect management, change management, and project management. [32]

There aren’t many study’s about how to do the traceability properly, so was developed the method Med-Trace which are a lightweight software traceability process assessment and improve-ment method for the medical device industry. [12]

Even if this or other standards are full of best practices, they also gave liberty to use a different organizational structure, which allows trying the challenge of doing with agile development.

(30)

2.4.2 Risk Management

Every project has a risk. Risk of delay the schedule, risk of overtaking the budget. . . they is so many that it is harder to list them all at once. But why is needed to identify? If you know that has a chance for the risk to happen; then it will be good to be prepared to find out a solution or even a way to avoid the risk from happening. This would apply for simple things in real life; knowing what could happen, it can be prepared to deal with it. In the scenario of medical devices software there are elements of risk management:

• Patients; • Operators; • Third parties; • Environment. [31]

On the way to do risk management is also managing the responsibility of the risk and try to level in the same way as in the figure2.2.

Figure 2.2: Definitions for probability and severity [31] .

(31)

2.4 Medical device standards 11

There are some foundation standards that help using risk management in the life cycle of the software. One of them is ANSI/ISO/AAMI 13485, “Medical Devices—Quality Management Sys-tems—Requirements for Regulatory Purposes, Int’l Standards Org., 2003” it provides the frame-work for a quality system for medical device manufacturers and requires establishing a risk man-agement process based on ISO 14971 and using it throughout the product realization process. And the ISO 14971, Risk Management—Application of Risk Management to Medical Devices, Int’l Standards Org., 2000 which defines several risk management terms and provides a framework for an effective risk management process. [31]

Having standards are important, as said before, to obligate the company to follow the best practice possible. But still have many problems, the risk management should start with the plan of the project, not in the end or when some problem happens and must act. It should be followed throughout the project.

(32)

(33)

Chapter 3

State of the art - Process and

Methodologies

This chapter focuses on the background of the process and methodologies to help in this thesis.

3.1 Agile Methodology

Agile software development has been adopted over the years by many companies all over the world. Agile is a mindset that involves adaptability and delivering value to the customer. More than optimizing the process of development is a way to prioritize and improve the software with time. Agile can be one alternative for the development of medical devices, but the biggest chal-lenge is to assure that the software maintains the compliance to all required regulations in each release of this software.

There are not many studies about a process that can guarantee compliance with the regulations and standards and still improve the deliveries. One aspect is that the main goals of the FDA are efficacy, safety, and security. Doing that with only pure Scrum, for example, is the challenge.

It is difficult for the company to change from waterfall to agile, especially if the clients are antiquated and have difficulty changing. Who works with development is used to changes, always has a new technology or a new approach to adapt to the project. If the developer does not follow the new tendencies is going to be behind in the market. So it is going to be the projects with software for medical devices. It will become more challenging to find a developer who wants to still work with the waterfall model.

Adapt is necessary, but has to be adequate for the regulation and standards as well. It is necessary to understand more about the agile methodologies that are used today.

The easiest way to understand agile is by analyzing the agile manifesto:

"Individuals and interactions over processes and tools Working software over com-prehensive documentation Customer collaboration over contract negotiation Re-sponding to change over following a plan"[9]

(34)

14 State of the art - Process and Methodologies

These sentences seem to be the opposite of what the regulations and standards advise to do it. People tend to think about a lot of documentation and evidence that it was done what they demand. However, not necessary is this, of course, need to put evidence but still can use with agile. The next topics will show the possibilities to help with the regulation and standards in medical device software.

3.2 Scrum

According to the scrum guide[36], Scrum is a framework within which people can address com-plex adaptive problems while productively and creatively delivering products of the highest possi-ble value. Scrum is:

• Lightweight

• Simple to understand • Difficult to master

Scrum can be used to research and identify viable markets, technologies, and product ca-pabilities to help with software medical devices. Although it has not a structured practice for implementation, the idea of sprints and continuous delivery is handy for the challenge to put that in the market of software medical devices.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. [36]

The Product Owner is responsible for maximizing the value of the product resulting from the Development Team’s work. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. [36]

There are special events like the Sprint, Sprint Planning meeting, Daily Scrum, review meet-ing, retrospective meetmeet-ing, and refinement. To optimize the time always has a time box in each meeting to be more productive in the development.

Scrum’s heart is a Sprint, a time-box of one month or less during which a "Done," useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. [36]

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. [36]

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. [15] A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the

(35)

3.3 Extreme Programming (XP) 15

Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collab-orate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. Daily Scrum is an informal meeting, not a status meeting, and the increment presentation is in-tended to elicit feedback and foster collaboration. [36] The Sprint Retrospective is an opportunity for the Scrum Team to inspect and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and before the next Sprint Plan-ning. [36]

They are also the scrum artifacts that follow in the process. Like the product backlog, sprint backlog, Increment. Many get confused with the difference between the product backlog to the sprint backlog. The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. [36]

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment. [36]

So, the product backlog is every scope that the product has, and the sprint backlog is only the scope that is going to enter the Sprint, so it is part of the product backlog. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in usable condition and meet the Scrum Team’s definition of "Done." An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The Increment is a step toward a vision or goal. The Increment must be in usable condition regardless of whether the Product Owner decides to release it. [36]

3.3 Extreme Programming (XP)

It is a software development methodology that has evolved from problems caused by long devel-opment cycles of traditional develdevel-opment methods. The term ’extreme’ comes from taking theses commonsense principles and practices to extreme levels. (Beck 1999) [6]

The extreme level came to facilitate changes and to produce higher-quality software. They can also improve the time of development because the developers work in pairs, which improves the quality of the code and the maintenance.

Like other Agile Methods of development, XP aims to provide iterative and frequent small releases throughout the project. The paradigm of Extreme Programming was built with five fun-damental values: Simplicity, communication, feedback, respect, and courage. [8] Also focuses on the phases shown in Figure 6: Exploration, Planning, Iterations to Release, Productions, Mainte-nance, and Death.

(36)

Figure 3.1: Life cycle XP process. [6]

In the course of planning, a series of requirements-gathering practices are carried out where the technical team is expected to gain business knowledge of the solution. These requirements manifest themselves in the form of user stories and map directly to tasks. The client is directly involved in the construction of the project and the specification of acceptance criteria and tests. [42]

3.4 Test Driven Development

The first step o implement TDD is to write the tests before the software is developed. Then the tests are automated, so it will be able to run anytime. For the regulation of medical device software, it is an excellent choice to use for the verification and validation part since the tests are extensive and with this method could save a lot of a time of testing. For the context in medical device software, this can prove to be a significant ally since it is needed to be done many tests to consider the software done. If the tests are thought before the developer of the code itself, this could also help estimate the effort more appropriately. Some projects related even that the coding is not the part that takes more time to be done, the tests are, and it is impossible to think that a medical device of any kind puts the focus of testing behind in the process. It is fundamental to have all the tests, so TDD can improve the time spent on the testing and divide some with the coding. Validation is one requirement that is fundamental for the regulations, and TDD was born validating the code itself and with that have the consequence of more quality and clean code.

TDD has three phases: [34]

(37)

3.4 Test Driven Development 17

• Green: Write as soon as possible the production code enough to pass this unit test even if it allows the "worst" solutions. Of course, if a clean and straightforward solution appears immedi-ately, it must be realized, but otherwise, it is not severe, the code will be improved incrementally during the refactoring phases. The aim here is to obtain the green bar of success of the unit tests as soon as possible.

• Refactor: This phase is often neglected but is essential because it eliminates possible code duplication but also makes it possible to make changes in architecture, factorization, presentation. This refactoring concerns both the production code and the test code and must not modify the program’s external behavior, which is materialized by a test execution bar that remains green.

The Figure3.2below exemplifies the phases above descriptive.

Figure 3.2: TDD principles [34] .

With this process, the productivity of the developers also increased. TDD helped in the case this paper mention in section 8 that they concluded that it would not be possible for them to apply agile without TDD because of the volume of testing and the Sprint time. TDD could be combined with other agile methods to integrate the compliance needed for the medical device software.

(38)

3.5 Behavior Driven Development (BDD)

BDD is a software development practice to write scenarios from the user perspective that evolved from TDD. It uses the Gherkin language to write the cases, and with that, it is possible to au-tomatize the latter into tests. One of the many advantages of using BDD in the project is that the scenarios should be written together with the stakeholders and the developer team, so the entire team knows what the project is about.

For the case study in Healthtech [11] that changes from waterfall to agile using BDD, they experience an increase in communication, which results in better collaboration. It was easier to formalize a standard in the test requirements that help with the system validation. Traceability was a goal, too, because of the transparency to all stakeholders. Another benefit was that the time-consuming tasks were better harnessed for other tasks since BDD is mostly automated. To ensure continuous compliance before every release, they generated comprehensive testing reports that allowed the stakeholders to review and confirmed that defined test scenarios were meaningful and covered the product requirements.

The automation available using BDD saved time and cost in that project, critical to small organizations such as ours. Finally, significant changes can be deployed with thorough validation and test requirement coverage to accelerate the development process. [11]

Using BDD could be a way to maintain the releases with the proper standard and regulation that MDD requires. It has automation as an ally to keep managing the changes and keep the traceability alive even with the changes.

3.6 Compliance with IEC 62304:2006

To develop quality software is needed so much more than just coding. There are areas of the software that need to be included in the process to comply with the standard. In this chapter, the goal is to explore some of these crucial areas and complement developer medical devices.

3.6.1 Configuration Management

Software configuration management is the control of the evolution of complex systems [14], which means that every software should be known, tracked, and managed.

This area was adapted from other institutions and was thought in the context of software. There are several benefits when the project uses well the CM:

1. Easily recovery with rollbacks;

2. Reliability with less chance of downtime; 3. Easily scaling;

(39)

3.6 Compliance with IEC 62304:2006 19

There is a process to follow to develop a good CM. First, the phase of configuration iden-tification needs to identify which needs to be maintained. Second, the configuration control is responsible for control the changes that will happen. Third, there is the configuration status ac-counting, which provides the current state of the development, and the history can be traced. Fourth, the configuration audit is to keep register the changes that can be made. More information in the image3.3.

Figure 3.3: Configuration Management and Planning [10]

Configuration Management is a perfect fit for agile methodologies since it helps to keep the velocity high and is also inside the process of DevOps.

3.6.2 Validation

Validation is not only testing the software. If only has validation in this phase, then it is counting that the test will be so perfect that it would validate the entire project. Verification also is not only testing, included but also has other activities. It is clearer this representation in the Figure3.4.

In agile, two questions teach what validation is:

"Are we building the right product?" and the question for verification: "Are we build-ing the product right?".

There is regulatory guidance that defines validation as "Confirmation by examination and pro-vision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled" and verification as "Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase" [39]

(40)

Figure 3.4: Relationships between validation, verification and testing [40] .

It is secure to affirm that needs evidence to prove that the validation and verification were done correctly. But must be objective evidence is something to be based on a fact.[40]

3.6.3 Verification

Verification and validation go side by side, they are related, but both are fundamental to deliver-ing the software with the required requirements and quality. Verification activities include review, evaluations, or actual tests that are graphically shown to verify that the design outputs are consis-tent with the requirements. [40]

In figure3.5can seem that verification and validation are redundant, but the same way that is a good practice to have the front and back end prepare for some exception in the process works too. So the validation will confirm that what was proposed in the first place at the end was the same, and the verification works in the middle to guarantee that everything will work correctly.

3.6.4 Software Life Cycle

A software life cycle is a way to organize building with some milestones, metrics, or control points in a more organized way. There are some common characteristics:[40]

• Identifiable phases; • Input to each phase;

• Activities to be performed in each phase; • Outputs of each phase.

When the subject is the medical device, the life cycle must be adapted because of the com-plexity and must emphasize the development and maintenance of the software. [40]

(41)

3.7 V-model 21

Figure 3.5: Design controls, verification and validation [40] .

A single life cycle for software in a company is not ideal because it should change with the software type that it is developing. Also, it is essential to have one because it is a way for outsiders to know that it has a process to guide and control the process. If it has control, it will be easier to identify where the problems are and how to improve even the process itself to help build quality software. It can be economical to know the schedule and the budget in a more precise way.

One way to find out the problems in the life cycle is with metrics. How many bugs were found in a specific phase; for example, it could help study more and understand what happened to cause bugs. If it has a few bugs, it would be an excellent example to put in more projects.

How to choose the best life cycle is a question that many companies are struggling with. The problems are always the same, requirements changing, and mistakes like lack of communication between the team and many more. There is not yet one solution for all of these, but the life cycle can help solve some of them. Nevertheless, it still must be careful about it because sometimes the process itself can be the problem if it is not adequate for the project and who was supposed to follow the activities start not to be doing it as the process demand it. So, there are some options to choose the more adequate in each case.

In this table3.1, there are four options of the life cycle and has a summary of the pros and cons of each one.

As was illustrated, there is no perfect approach, and it will depend on the software and what would work better in that case. After choosing the best-fit life cycle, the plan must create a quality system; with the review, coding software, verification, and validation testing, and more are all part of the software life cycle plan.

3.7 V-model

Even if the regulation does not determine, which SDLC to follow, medical device software devel-opment organizations typically follow the V-model. The V-Model shows the relationship between

(42)

22 State of the art - Process and Methodologies Systems development life cycle Pros Cons Traditional Waterfall

Intuitive, easily understood. Established and well known.

Enforces design before implementation. Control points clearly demarcated. Leaves “clean” design history trail of documentation.

Not realistic for more than simple software. First software available late in life cycle. Testing starts late in life cycle.

Requires interpretation and modification to make it work for real projects.

Modified Waterfall

Intuitive, easily understood. Established and well known.

Enforces design before implementation in a slightly more realistic way. Control points clearly demarcated. Leaves “clean” design history trail of documentation and updates.

Still slightly unrealistic . . . but better. First software available late in life cycle. Testing starts late in life cycle.

Still requires interpretation for changes requiring more than single-phase updates.

Sashimi Waterfall

More indicative of how some projects are done (vs. should be done?) Recognizes the need to “peek ahead” in life cycle.

Design-before-implement still present but to lesser extent.

First software pieces available earlier in life cycle.

Control points less clear. Documentation of design history challenging.

Configuration management (synchronization of design documents, code, and test documents) more difficult. Progress metrics and forecasting difficult

Spiral

May be best model for software whose requirements need to be discovered iteratively. Gets prototype software in users’ hands most quickly.

Opportunities for more formal

development in later stages of the spiral. Good for user interface intensive software in which user preference

is a key driver of requirements.

Integration of risk management is explicit and in-line, not supplementary.

Not appropriate for software whose early prototypes could harm users.

Tracing evolution of requirements back to user needs may be challenging.

Temptation to end the life cycle at the last “good enough” prototype without

adequately reviewed design or adequate testing.

Metrics for project management, forecasting, and process improvement challenging

(43)

3.8 Related work 23

the two sides of the development process. This relationship is used to determine whether the stage has been completed successfully. [26]

The V-model has a series of linear stages represented in Figure3.6.

Figure 3.6: V-model [11] .

3.8 Related work

3.8.1 CochlearTM

There was one case in 2008 at the company CochlearTM[33] that build solutions for severely to profoundly deaf people. They needed to adhere to the highest level of the medical device standards and comply with Traditional Waterfall.

The Cochlear than tries to build with agile and developed his product development process based on the V-model, shown in Figure3.7.

Even with this process, they had issues on introducing agile in the company like:

• the disparity between using an Agile methodology in the software department versus using a waterfall/iterative process throughout the rest of the organization

• the identification of the recipient safety aspects of a product and the mitigation of such risks in a structured and traceable way

(44)

Figure 3.7: Cochlear’s Design Control Process for software [33]

• the long validation cycles required to validate the marketing claims and ultimately the user requirements

• the extensive manual verification testing required to verify that the electrical stimulation of the implant under software application control is within safe limits

• device drivers with a large amount of legacy code that was neither unit tested nor conducive to any other automated testing type. [33]

The project definition had complicated setting the timeline with all the estimations and expe-rience based on a different development process.

In the product definition, they change the use of the Software Requirement Specification (SRS) for user stories based on XP.

In the case, they use sprints of 4 weeks, and for the user, story be considered done, it has to be implemented and tested. The definition that it showed impossible to accomplish in the time of the current Sprint since they had to do safety testing as the regulation demands. Because of that, they needed to decide if they were going to spend time automating testing or keep going without delivering and degrading the velocity. That was the point that they implement TDD using the framework FIT. When they made this decision, they got it right the timing and started to see the sprints happening.

Although they could implement TDD, they still did the clinical validation manually to ensure that they match all the requirements. [33]

This case was fascinating because it could be analyzed to create a process complementing their issues and improve their difficulties. However, it has proved that it is possible to work with agile and regulations for medical device software, and with agile, it will improve the efficacy of the developer team and the quality of the code.

(45)

3.8 Related work 25

3.8.2 MDevSPICE R

This article is the most recent case published. The work was done in 2019 with a framework MDevSPICE , XP, Scrum, and DSDM.R

They first analyzed the XP with Scum for the management and technical processes perspective. However, the mapping of these two methods was not enough to cover all medical requirements’ needs. Then they performed a new mapping with the Dynamic System Development Method (DSDM), which provides practices and the work products to cover the full software development life cycle. Its emphasis on governance, adequate documentation, and specific roles. [28]

This study was an extension of the previous mapping studies done with XP and Scrum to in-clude DSDM analysis. It was revealed that have ways for the methods XP, Scrum, and DSDM be combined, how these agile models can support each other, and which additional system and soft-ware processes and practices should be considered to ensure medical regulatory compliance.[28]

MDevSPICE is a framework developed to help with all the regulatory requirements speci-R

fied in the standards. It is an integrated framework of medical device software development best practices.[28]

MDevSPICE was based upon the old ISO/IEC 15504/SPICE, the ISO/IEC 33000 series.R

To build a process assessment standard that includes requirements from a complete number of medical software development and software engineering standards. [28]

The process created can be illustrated in Figure3.8.

(46)

Another process that was used in this case was the Dynamic Systems Development Method (DSDM). It is an agile project framework that provides practices and products to cover the full software development life cycle. It was initially developed in 1994 by a large group of practitioners for rapid application development. DSDM advocates fundamental agile principles such as Enough Design Upfront, Never Compromise Quality, and Collaborate. [28]

It was performed in the case of a systematic literature review (SLR) to specify the agile meth-ods used in the medical device software development domain. The study that was done was in 126 papers and reduced to 33, as illustrated in Figure3.9.

Figure 3.9: Paper screening process [28]

Their analysis has revealed that Scrum, Extreme Programming, and Test-Driven Development are the most used agile methods in the medical device software development (MDSD) domain. Other research was that Lean Development, Feature Driven Development, and DevOps are the other agile methods referred to in the papers. However, there was no evidence on the utilization of DSDM in the MDSD domain.

They also discovered that the scaled agile models: Disciplined Agile Delivery and Scaled Agile Framework was not provided in the specific solutions for safety-critical projects. It was an-alyzed by them that performing daily stand-up meetings and using burn-down charts enable teams to uncover issues earlier, monitor the effect of changes, and estimate better. Iterative development enables accommodating changes more comfortable and getting early feedback from the customer, and managing scope creeps. [28]

On the other hand, according to the papers, it was also analyzed which agile method was not suitable to implement in the medical device software development. R-Scrum augments the Scrum method with specific roles and artifacts. In addition to the Scrum roles, R-Scrum defines a "Vice President (VP) of Quality" role who verifies that the output(s) from each Sprint adhere to the required procedures and a "Quality Control" role who produces system test documentation and executes system test scripts in line with required standards and product specification and documents all test results for release review. [28]

One of their goals was to find what could extend their framework MDevSPICE . It wasR

analyzed that Scrum covers project management, requirements specification, integration test, and system test stages/activities. XP presents solutions for requirements specification, design, code, unit test, integration test, and system test stages/activities. DSDM, however, covers the entire life cycle. While Scrum and DSDM provide practices for project management, XP does not. [28]

(47)

3.8 Related work 27

This paper was fascinating because it could join other papers in one. It is theoretical to prove that combining more agile methods will help cover all the standards and regulations’ requirements. Still have more agile methods to explore, and the job is still not over, but at least with this work is not from zero the study of new processes to full fill everything to give a better medical device software with safety.

3.8.3 AV-Model

It is an agile adaptation for the V-model. It could be more comfortable for the companies to adopt because of the process’s similarity since any change must be the phase of adaptation and learning. It was a hybrid model that, in the mapping study was identified 13 practices such as "Iterative Development," "Use case/User Stories." [26]

Figure 3.10: AV-Model process. [26]

The objective of the development of this model is to resolve problems associated with fol-lowing a plan-driven software development life cycle while reaping the benefits of utilizing agile practices.[26]

This AV-Model also has two stages of validation:

1) Expert Opinion: Once the model has received validation from the industry, it will be dis-tributed to experts in medical device software development. An agreement has already been made with members of the IEC 62304 committee and members of the TIR 45:2012 committee to provide validation of the model. By eliciting this form of feedback, the model aims to gain acceptance in the standards community.

2) Implementation: Once the model has undergone the Expert Opinion validation, it will be adopted by a medical device software development organization. A medical device software orga-nization has agreed to implement the model once it is completed and passed through each of the steps of validation .[26]

(48)

Hybrid agile methods have been shown as a viable option to secure standards and regulations. This case was interesting because it adapts one model that is one of the most used for medical devices software.

(49)

Chapter 4

Previous Work

This study is a sequel to the thesis made by Zamith [41] named "Desenvolvimento de Software para Dispositivos Médicos: Uma Abordagem Ágil". His study observed many improvements and had a solution to the process based on this study. It was based on the idea of the methodology Scrum to improve the process in the medical devices field. The proposed solution is summarized in figure4.1.

Figure 4.1: Scrum for medical devices [42] .

(50)

30 Previous Work

4.1 Initial Process

This process was made to comply with the standard IEC 62304:2006 and still using agile to im-prove the quality in every release. The process was started by doing the product vision, where it is about to work in the product’s global idea. This part should have identification of which classifica-tion of security the medical device has. The identificaclassifica-tion of the tools, standards, and deliverable that the project will have. Also, the backlog should be ready and an architectural document.

After this, it will be the Sprint 0, a revision of the product backlog, update the documentation, and have the definition of done to all teams. [42]

Every sprint should have a time box between two and four weeks. As a result of every sprint should have an increment of the product. The user stories that will be developed in the sprint should not have changed since the sprint started. Here the process is equal to SCRUM. QA check-point was one phase added to audit the deliverable and evidence compliant with the standard. After this, the checkpoint should have a report of non-compliance, and the measures should be-come tasks. The QA checkpoint was based on the R-SCRUM.

The process created by Zamith still involved all ceremonies of SCRUM in making the team more capable of following the life cycle of SCRUM. [41]

Another change was a QA Team that is not part of the development team, which is accountable to do the QA checkpoints.

Was proposed several practices that should be applied in the process like TDD, Refactoring, Build Process Automation, Automatic Deployment process, Automatic tests, and Continuous In-tegration. [42] These were actions that could improve the quality and assist the agile process with standard compliance.

4.2 Compliance with standard IEC 62304:2006

It was observed in the study that are some tools that allowed evidence that can be useful for the standard. Like Version Controls, Issue Tracking Platforms, and Integrate Environment Develop-ment. [41]

In the field of requirements, user stories are proposed, which is a common practice when using an agile methodology. One of the many advantages of using this is that the stakeholders are involved.

The definition of done is essential to be aligned with the team once it provides the developed work quality. Some practice is advised to be done at this point:

a) Code produced;

b) Success compiled project;

c) Unit tests, integration, and system;

d) Deployed in a test environment without errors; e) Refactoring activities;

(51)

4.2 Compliance with standard IEC 62304:2006 31

g) Code Review;

h) Fix all anomalies in the process of verification. [41]

4.2.1 Verification

Verification is fundamental for the standard IEC 62304:2006 one way to reach the requirements demanded. One practice that should be with Pull Requests which have evidence to prove to the standards.

Must have a rigid verification in Requirements, Architectural, and Planning documents, espe-cially if it is the sprint zero. [41]

4.2.2 Configuration Management

The propose was to have an automation process to do it and document. Automation is fundamental to the changes that the project can have. So it is necessary to have version control.

4.2.3 Traceability

It is fundamental to have links between the artifacts and data of the project. If the software is crit-ical, safety is a priority and must have traceability between the artifacts. Traceability contributes to more understanding of the product itself. [42]

It is essential to connect every area with requirements, development, tests. It was advised to use the platform issue tracking. [41]

4.2.4 Test

The standard IEC 62304:2006 demands three levels of testing: a) Integration

b) System c) Regression

These items should have evidence and better if it is automatic.

4.2.5 Audit Checklist

Each section of the checklist corresponds to a chapter IEC 62304: 2006 standard and were use to validate in the academic case of this study. [41] The checklist have the audit information, project details and types that will evaluate each item to compliant until observation.

The audit scope were Project Managment, Configration Managment, Software Planning, Risk Managment, Verification, Delivery, Requirements analysis, Safety Classification, Software De-sign, Software Testing and Software Construction.

(52)

32 Previous Work

4.3 Limitations to validate the process

In the thesis of Zamith [41] were observed some limitations when he validated the solution in an academic case and the interviews. Like every project with a previous similar one, it is an excellent practice to learn the previous lessons learned to avoid them from happening again. So it was punctuated by him some limitations that he had to deal with due to the academic case environment that the author could learn before validated mine.

• The study’s validation was made with an academic case, which was only in the project’s final moments. Because of that, it was difficult to analyze every step and observe;

• It was not possible to find elements to perform all the necessary roles and the absence of a Product Owner made some important actions impossible during the process;

• It is difficult for companies to put a separate team to do the intern auditing;

• The process is tied with the TDD, and not many developers have experience on this; • The validate case does not have many of the scenarios of tests made.

Even with the solution proposed, the process cannot be fully validated due to the limitations above.

4.4 Proposals for the limitations

Based on the experience of the previous work with the objective to improve the process already created, and more study in the agile area, this thesis proposes improvements to get a more adapted process that could work at any company and not only focus in the regulation but also improve the process by an in-depth study in the agile methodology so that the developers and the work team can also have benefited by using the process.

It is essential to follow the process at the conception part to understand more of the product and what process will work better. The previous work was not possible to follow from the beginning of the case because the process was still being developed. Otherwise, this thesis could follow the academic team in the conception part of the process already made.

Another issue was about quality assurance in the process, which is a primordial area to guar-antee compliance with the medical area’s regulations, security, and safety. Another proposition beyond had the quality test outside to audit also includes a QA Team inside the developer team to follow and respect the regulation. Having a QA member inside the team will help limit getting more visibility of test scenarios if the tester is in the developer team.

Today it is possible to find several technologies and processes that will help in the test automa-tion. Know developer TDD, unfortunately, could not be the knowledge in the developer team, so it is useful to have other techniques with agile that are more common for developers to use than TDD. So that will solve the technical debt that the team could have, and the team can be trained to other projects.

(53)

4.5 Validation Process 33

4.5 Validation Process

For a project, be agile is not necessarily one methodology but the change of the mindset. Because of that, when this study was started, the plan was to use the same project and compare the results. However, it is natural that overtime on a project, people will gain more experience, and this is what happened in this thesis; why compare the same thing if the author already learned some necessary improvements to work in the process?

Because of that question in this study, the validation was done by the author with continuous improvement.

The first step is to tested in the academic case using the process created by the previous work presented in this chapter. Next were analyzed what could have been better and created a first version of the process by this study. Later on, the first version was validated by one agile expert, and with the feedback of one interview were made a second version of the process and validate by the last two interviewees and then with the feedback of the interviews was generated the third and last version of this study process presented in chapter7.

This thesis will use this approach to validate the study, and it is exemplified in the diagram below4.2.

(54)

34 Previous Work

(55)

Chapter 5

Academic Case

This chapter presents the academic case experience validating the proposed process and recogniz-ing improvements for this study.

5.1 The project - Hive Health

Because of the pandemic conditions in 2020, this study could not be validated in a real com-pany, but it was possible to observe and act in an academic project in the course PMIE (Project Management, Innovation, and Entrepreneurship) from the Master in Software Engineering at the University of Porto.

The client of this group of students was the Hospital Pedro Hispano, which had the objective and motivation to create an information circuit from the patient’s headache diary to the doctors to reduce the number of appointments.

The main functionalities would be developed in two systems, one mobile app for the patient integrate with a web application in which the doctor would have access to the data made by the patient in the app.

5.1.1 Academic Validation

It was possible to use the process done by the previous work done. That provided that the study could have started to validate the process at the beginning of the project. Not giving the students more tasks but still following the process so that the validation will be an inside job of quality. To ensure the process’s precision, the author was part of the team and helped with the quality.

First, the team evaluated which methods they already have done and which were necessary to add to the full process. The author aligned with the Leader of the project that they were doing already the following practices:

• Product Vision • User Stories

• Definition of Done (Verification)

Agile development model for certifiable medical device software

F

E

U

P

Agile development model for certifiable

medical device software

Erica E. F. Lima

Agile development model for certifiable medical device

software

Erica E. F. Lima

Mestrado em Engenharia de Software

Abstract

Resumo

Acknowledgements

Contents

List of Figures

List of Tables

Abbreviations

Chapter 1

Introduction

1.1

Context

1.2

Motivation

1.3

Document Structure

Chapter 2

State of the art - Regulation

2.1

Medical Devices Regulation in EU

2.2

Medical Device

2.3

Software as medical device

2.4

Medical device standards

Chapter 3

State of the art - Process and

Methodologies

3.1

Agile Methodology

3.2

Scrum

3.3

Extreme Programming (XP)

3.4

Test Driven Development

3.5

Behavior Driven Development (BDD)

3.6

Compliance with IEC 62304:2006

3.7

V-model

3.8

Related work

Chapter 4

Previous Work

4.1

Initial Process

4.2

Compliance with standard IEC 62304:2006

4.3

Limitations to validate the process

4.4

Proposals for the limitations

4.5

Validation Process

Chapter 5

Academic Case

5.1

The project - Hive Health