information systems
Computer System Validation
Applying GAMP 5 and the
V-Model to Agile Development
This article will explore an alternative approach to the traditional V-Model and
how it can be applied in a more iterative software development environment.
I 
n 2008, GAMP® 5 introduced what is now a widely
accepted approach to risk-based computer system
validation within the pharmaceutical and biotechnol-
ogy industries. This approach can be found throughout
the traditional System Development Life Cycle (SDLC)
from concept, through the project phase (including an
initial system assessment and requirements analysis),
to operation and retirement. The type of life cycle being
considered in this article is one that includes custom
software development activities such as coding and unique
configuration (GAMP Category 5 – Custom Applications).
Although the guidance of GAMP® 5 does recognize that
linear and/or waterfall development models are not always
the most applicable or appropriate in all cases, the guidance
does still highly identify with and utilize the V-Model to
demonstrate and provide examples for a typical system life
cycle approach.1
In recent years, particularly in Contract Research and
Manufacturing Organizations (CRO/CMO), agile or iterative
development has become very much the norm in develop-
ing new and market differentiating software solutions.
The needs of customers are rapidly changing and contract
organizations need to be more flexible to respond to grow-
ing client expectations, desires and business requirements.
Often these solutions evolve through close partnership and
collaboration between the customer and client, thus exploit-
ing the benefits and strengths of Agile. However, the need to
remain compliant and maintain a system in a validated state
can be challenging in using such a dynamic approach. This
article will explore an alternative approach to the traditional
V-Model and how it can be applied in a more iterative soft-
ware development environment.
46 Supplement to PHARMACEUTICAL ENGINEERING OCTOBER 2014
by Eric Staib
The Model
Typically, the V-Model depicts the waterfall SDLC as shown
in GAMP® 5.2 However, as seen in Figure 1, the V-Model
has been modified to present how an iterative development
life cycle could look. This is pictured as a “W-Model” with
successive development and release activities throughout the
project phase(s).
In this manner, multiple design and module/unit speci-
fications are created and/or revised with associated unit
and integration testing taking place. This cyclic activity is
representative of an Agile iteration or sprint.3 After suc-
cessive sprints, the necessary system/functional and user
acceptance testing shall be conducted in order to release the
system to production. In much the same manner that cod-
ing is conducted in a very quick and concentrated manner
according to Agile development,3 so are the documented
requirements/specifications, testing and fitness for intended
use being verified. In essence, the bottom of our traditional
V-Model has become much more dynamic, flexible and fluid
to accommodate the agile approach while still maintaining
the robust control, discipline and documented evidence of
the V-Model. Another way to represent the W-Model is a
“Mash Up” of the V-Model and Agile approach as seen in
Figure 2.
Risk-Based Approach
In order to make this “Mash Up” work and still do so in
an efficient and effective manner, the primary principles
of GAMP® 5 need to be fully leveraged and in some cases,
expanded to achieve a computerized system that is fit for
its intended use. For example, it must be prospectively
determined, or specified, as to what justification(s) shall be
used to decide upon the appropriate number of iterations
 information systems
Computer System Validation

Figure 1. Proposed “W-Model” (Modified V-Model) for iterative development.

that should take place prior to release. Other considerations under what circumstances? These considerations also must
may include: how will documentation be handled and/ be discussed with the process owner to determine how they
or updated? Will regression, system/functional and user will “accept” the system based upon what development test-
acceptance testing take place each time? How often, and ing (e.g., in some cases, a possible “hardening” or system

Welcome to the NEW Digital Edition of

THE OFFICIAL
TECHNICAL
MAGAZINE OF ISPE

A quick look at enjoying our interactive features!

1 SEARCH for specific articles or content.

2 Easily NAVIGATE through the issue. 1 2 3 4 5 6 7
3 Click directly on the page to ZOOM
in or out. Fit the issue to your screen. 8
4 1 PAGE / 2 PAGES View an issue one 9
page at a time or in spreads.
10
5 SHARE an article or page via email
or social media. 11
6 PRINT any or all pages.
7 DOWNLOAD the issue to your desktop.
8 View the table of CONTENTS and easily
navigate directly to an article.
9 Click PAGES to view thumbnails of each
page and browse through the entire issue.
10 Easily browse all BACK ISSUES.
11 If you are having problems navigating
the issue click HELP for assistance. 4

www.PharmaceuticalEngineering.org Illustration courtesy of

OCTOBER 2014 Supplement to PHARMACEUTICAL ENGINEERING 47

 information systems
Computer System Validation
Figure 2. V-Model and Agile approach “Mash-Up.”
stabilizing sprint4) has already been done. This should be a
topic of discussion between developers and various busi-
ness unit team members during frequently held meetings.
Ideally, risk assessment of individual user requirements and
system functionality also should take place and be leveraged
in making decisions. Once the system has been released into
production, the team must decide how additional sprints
and development activities will take place. How will design
changes and potential impact to original requirements be
addressed? At what point do multiple design specifications
and/or requirement documents get consolidated? No mat-
ter what the answers to these questions may be, these basic
principles still apply:
• Product quality, data integrity, and patient safety must be
assured.
• Fitness for intended use must be demonstrated.
Conclusion
Being able to manage a combined “Mash-Up,” as presented
above, and still reap the benefits of each individual model
or approach is no easy task. The establishment of robust
and mature configuration, change, and document manage-
ment systems must have occurred. These systems must be
efficient and effective enough to keep pace with the defined
iteration and sprint cycle times determined by the project
team. Another key element is managing the amount of detail
specified within the URS/FS, by maintenance of stable
and high level requirements.4 This ensures that the Agile
development, which has essentially replaced the bottom
portion of the “V,” will not be overly constrained and/or bur-
dened by items that have the potential to change over time.
48 Supplement to PHARMACEUTICAL ENGINEERING OCTOBER 2014
Finally, the team members themselves
must be highly skilled, experienced and
trained individuals. They must possess
a complete understanding of both the
traditional V-Model and Agile approach,
and the combined “Mash-Up” so as to
ensure successful implementation. As
with any project, regardless of the life
cycle approach or model being followed,
team communication, personal aware-
ness, and a mutual respect for following
the process are key elements for success-
ful delivery.
References
1. ISPE GAMP® 5: A Risk-Based Ap-
proach to Compliant GxP Computer-
ized Systems, International Society for
Pharmaceutical Engineering (ISPE),
Fifth Edition, February 2008, Sections
3 and 4, www.ispe.org.
2. ISPE GAMP® 5: A Risk-Based Approach to Compli-
ant GxP Computerized Systems, International Society
for Pharmaceutical Engineering (ISPE), Fifth Edition,
February 2008, Figure 4.4 – Approach for a Custom Ap-
plication, www.ispe.org.
3. Balaji, S. and Sundararajan, M., “Waterfall vs. V-Model
vs. Agile: A Comparative Study on SDLC,” International
Journal of Information Technology and Business Man-
agement, June 2012, www.jitbm.com.
4. Cockburn, A., Agile Software Development (Second Edi-
tion), 2006.
About the Author
Eric Staib is currently the Executive
Director of Corporate Quality Assurance
at PRA Health Sciences. He has 16 years
of pharmaceutical industry experience
in various GXP areas, including direct
experience in quality systems development
and management, QC microbiology, quality engineering,
information technology, and laboratory operations. He holds
a BS from James Madison University in biology, a MS from
Temple University in quality assurance and regulatory af-
fairs, a graduate certificate from Lehigh University in project
management, and a MBA from Drexel University in pharma-
ceutical management. Staib is also Vice Chair of the GAMP
North America Steering Committee, and co-chairs the R&D
and Clinical Systems Special Interest Group (SIG).