Agile Methodology of Development and How to be Compliant

Agile Methodology of Development and How to be Compliant

Yerramalli Subramaniam (CliniOps Inc., USA), Avik Pal (CliniOps Inc., USA) and Arindam Dey (HCL America Inc., USA)
Copyright: © 2016 |Pages: 16
DOI: 10.4018/978-1-4666-8726-4.ch013
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Given that Agile software development is preferred methodology for products and services in life science industry, in this chapter we will describe how to adopt Agile software development process and still be compliant. We will focus on few Agile methodologies and provide details on what design controls we can adopt in order for the product and process to be compliant. We will also focus on some of the tools that can be used to help put such design and process control in place where we can have complete transparency and traceability.
Chapter Preview
Top

Introduction

Software industry started a few decades ago focusing on some core sectors of industry such as banking but now it is part of almost every industry. Historically, most of the software development was done through waterfall methodology. In this, all the requirements are made available upfront and after the development is complete, there is a dedicated testing phase, which focuses more on quality control of the software. This methodology works well when there is well-defined set of requirements. This also helps in contractual terms where there well-defined set of inputs, outputs and the results are measured against those cornerstones. But these days, because of competition, companies want to rollout products faster and want to be more responsive to voice of customers. As a result, most of the companies are adopting Agile methodology where continuous improvement and feedback is a critical part of the process. Over the years, Agile software development has adopted several approaches such as extreme programming, scrum, lean software development, etc. and they all share similar philosophy of adaptive, iterative and evolutionary development.

But when it comes to compliance, there are challenges to roll out the products faster with evolutionary development while still adhering to the compliance directives. Most of the compliance directives defined in 21CFR 820 (QSR) and it provides just broad guideline for compliance instead of going into details and “prescribing” the nuts and bolts of software development process. The onus is on the software development team to provide details of their development process and convince auditors how their design controls in software development process address the compliance guidelines and deliver a quality product. Apart from the development process, FDA also looks into the software quality/safety model, software maintenance and CAPA,which could be a part of safety risk management.

Agile vs Waterfall Process

Few decades ago, waterfall process was ubiquitous and was considered the standard way of developing a software product for medical devices and other life science product. Bell, Thomas E., and T. A. Thayer originally proposed this process in 1976 and in this process each stage of software development follows a sequential pattern. Requirements are gathered upfront followed by design, implementation verification, and maintenance.

In early 2001, software community proposed a new approach for software development and published the “Manifesto for Agile Software Development “. In contrast to waterfalls’ linear, structured and rigid approach, Agile process focused on incremental and iterative development. This followed the philosophy of fail early and fail often by frequent software releases and getting customers feedback for next software iteration release cycle. With short development cycles and releases, customers were able to use the product and the core philosophy was that a working version of software is a true measure of the progress of the project.

In summary, Agile methodology is more focused on the actual product than producing an exhaustive document in the requirements stage. Having an exhaustive requirements may make sense for engineering companies for building bridges, ships etc. but when it comes to software engineering, over the years companies have realized that the requirements do change because of several reasons – changing market condition, value proposition etc, and the software needs to adapt to those changes. Software professionals now realize the true value of Agile methodology because it is more focused on responding to changing market condition than sticking to an original plan. Unlike the waterfall method, the software development communities have also realized that Agile process is more about collaboration with customers and not about negotiating a contract from the requirements document. Finally, Agile puts more emphasis on individual’s interactions than on process and tools. This is not to say that Agile process is unstructured. On the contrary, it is process that is more adaptable to change in requirements, strict control of software quality and getting customer’s feedback on the product.

Complete Chapter List

Search this Book:
Reset