Biomedical engineering work is subjected to stringent regulatory constraints that mandate a robust engineering process that conforms to all pertinent regulatory guidelines and imperatives. Software development is an important component of any engineering project and as such, it should be equally addressed and properly integrated with the overall engineering process. To that effect, the following software development process is proposed. This process attempts to be well grounded in the nature of innovative Biomedical engineering work. There are inherent significant technology risks related to the development of innovative biomedical devices. These risks must be correctly identified, and mitigated throughout the entire engineering process. The main benefit of the software development process presented here is its explicit management of software risk factors as recommended by modern successful software development practices.

1. © 2005-2013 Pragmatic Cohesion Consulting, LLC
1
A Potential FDA 21 CRF 820.30 Compliant
Software Development Process
For Innovative Biomedical Industries
Inspired by Grady Booch – Object Solutions

2. © 2005-2013 Pragmatic Cohesion Consulting, LLC
2
1 The Software Development Process
1.1 Motivation for an improved software development process in Innovative Biomedical Industries
Biomedical engineering work is subjected to stringent regulatory constraints that mandate a robust engineering process that conforms
to all pertinent regulatory guidelines and imperatives.
Software development is an important component of any engineering project and as such, it should be equally addressed and properly
integrated with the overall engineering process. To that effect, the following software development process is proposed. This process
attempts to be well grounded in the nature of innovative Biomedical engineering work. For example, many innovative biomedical
products go through several successive needed refinements that initially explore the device concept and progressively yield more
mature and robust systems that meet FDA regulatory requirements. There are inherent significant technology risks related to the
development of innovative biomedical devices. These risks must be correctly identified, and mitigated throughout the entire
engineering process. The main benefit of the software development process presented here is its explicit management of software risk
factors as recommended by modern successful software development practices. This process also promotes the regular delivery of
tangible design history artifacts. The following three driving factors capture the essence of the proposed software development
process:
 Continuous Integration of software components and software with hardware components. The goal is to facilitate the detection
of risk areas throughout most of the development process rather than at a specific project phase.
 Incremental delivery of features through executable releases. This establishes a project rhythm that brings regular closures in
the ongoing development efforts. Also newly discovered issues can be scheduled to be addressed in future releases as opposed
to disrupting the current release ongoing efforts.
 Promote management visibility on project progress and quality. By making executable releases and their associated artifacts
milestones, management can tangibly access quality and also identify and mitigate risk factors
The software development process also addresses the following FDA 21 CFR 820.30 sections: b-Design and Development Planning,
c-Design Input, d-Design Output, e-Design Review, f-Design Verification, g-Design Validation, h-Design Transfer, i-Design Changes,
h-Design History File.

3. © 2005-2013 Pragmatic Cohesion Consulting, LLC
3
1.2 Major Software Development Phases
The following five phases are identified:
 Conceptualization main goal is to establish core requirements by bracketing the project risks and building a proof of concept
 Design Inputs Creation (Analysis) develops a model for the software system desired behavior. That phase develops a
common vocabulary and a common understanding of the systems’ desired behavior by exploring scenarios with end users and
domain experts.
 Design Outputs Creation (Design) creates the software architecture. It establishes a skeleton for the solution and lay down
tactical policies for implementation by drafting the system’s architecture
 Evolution evolves and deploys the implemented software through successive refinements. It is characterized by several
package releases for deployment.
 Maintenance is mostly concerned with managing post delivery evolution triggered by newly identified requirements.
The following table presents the goal and major activities of each phase.
Phase Goal Major Activities
Conceptualization Establish core requirements Bracket the project’s risks by building a proof of concept
Design Inputs
Creation - CFR
820.30 (c)
Develop a model for the software system
desired behavior
Develop a common vocabulary and a common understanding
of the system’s desired behavior by exploring scenarios with
end users and domain experts
Design Outputs
Creation –CFR
820.30 (d)
Create an architecture for the implementation Establish a skeleton for the solution and lay down tactical
policies for implementation by drafting the system’s
architecture
Evolution Evolve and deploy the implementation
through successive refinements
Refine the architecture and package releases for deployment;
further analysis, design, and implementation needed
Maintenance Manage post-delivery evolution Continue the system refinement to address newly identified
requirements
In the following section, pertinent FDA 21 CFR 820.30 sections will be cited as the software development process is presented.

4. © 2005-2013 Pragmatic Cohesion Consulting, LLC
4
2-Phases Detail Description
Conceptualization Phase
The conceptualization phase is very exploratory in nature. The development team and the potential users try to establish a proof of
concept for the software to be built. The creation of an executable prototype is favored for several reasons. First of all an executable
prototype is executable i.e. it is a functional software that contains many critical features. By being a tangible artifact, an executable
prototype gives the user community an opportunity to provide more accurate assessments of the perceived capabilities of the prototype
software. It is important to realize that the prototype aims only at proving the software concept; it is in no way a production quality
release. The prototype must be seen as a risk exploration tool that boldly tackles the most important software risk factors as they relate
to the overall product functionality. Because other engineering areas of the system (mechanical, electronics) are very likely to be also
going through this early conceptualization phase, the prototype software should ultimately demonstrate a proper fit in the overall
integrated prototype system. By emphasizing the creation of an integrated prototype system, obvious risks factors can be identified at
the software level or at the software/system integration level. A general vision of requirements is created during this stage in an
interactive manner by exposing the user community to the prototype system. With direct exposure to a tangible product, user
requirements captured at this stage are likely to be somehow more accurate.
The documented artifacts produced at this stage are (21 CFR 820.30 (j)): the executable software prototype, the software components
and software components integration risk assessment document, and the general user’s requirements for software document.
The execution of this phase involves software engineers, users, and domain experts. This early involvement of the user community in
the development process establishes communication channels that hopefully can last throughout the entire project life cycle.
The conceptualization phase complies well with the overall software development paradigm presented at the beginning of this
document. The integration of software with the rest of the system is achieved with the integrated prototype system, the idea of
incremental refinements and delivery of executables is established with the executable prototype which represents the first incarnation
of a series of releases that will grow in functionality and completeness as the project unfolds. Management visibility on risks factors is
made explicit with the creation of the software components and software components integration risk assessment document. With that
document in its hands, management possesses tangible material for defining a pertinent software risk management plan that will be
reassessed and executed as the project progresses.

5. © 2005-2013 Pragmatic Cohesion Consulting, LLC
5
The Design Inputs Creation Phase CFR 820.30 (c)
This phase is centered on the creation of Software requirements – in Engineering Terms. The system context document is an example
of such documents. It clearly spells out the boundaries of the software system under creation as it relates to external systems’ software
and non-software components. This document takes the shape of a list of inputs and outputs into and out of the software system. It
also specifies the required characteristics of these inputs and outputs so that they match the interface of the external systems.
Use case creation is another software engineering requirement definition exercise that focuses on formalizing the definition of the
software system desired behavior from the standpoint of a user. Use cases resemble scenario descriptions of user interactions with the
system and the corresponding system responses to user inputs.
A complementary approach to use case creation is the system functional analysis. It aims at grouping and decomposing the functions
of the system to discover the behavior embedded in it. That analysis strongly depends on the initial formulation of various scenarios
describing from a user standpoint what services might be needed from the system. Performing functional analysis reveals some
implied requirements that are not explicitly stated in the originating user requirements and that are discovered by a decomposition and
classification exercise. Inputs and outputs become valuable instruments to capture the interaction taking place between functions and
sub-functions in terms of data, material, or energy transformed or transported within the system and between the system and its
environment. The functional analysis of the system is also used to define precise system requirements that can be classified as input,
output, or functional engineering requirements. These requirements can then easily be allocated to functions, inputs, and outputs. This
allocation allows tracing engineering requirements to logical system elements.
Essential class diagrams are a software engineering artifact that logically groups system data structures and behavior into classes.
Essential class diagrams depict the most critical classes of the software system being developed. Relationships between classes are
also identified in these diagrams. The set of essential classes and their inter relationships constitute the Domain Model. The Domain
Model is an evolving artifact that gets refined as more knowledge about the system is gathered throughout the project life cycle. At the
analysis phase, the Domain Model embodies the best perception of the software system data structure and behavior thus far.
A revised software risk assessment is conducted at this stage (21 CFR 820.30 (e)). It focuses more on technical challenges identified
by the analysis work performed up to that point. Size, complexity, and innovative nature of the software can be better assessed at this
point. Non technical areas of risks related for example to the ease of user requirements verification and validation can be addressed at

6. © 2005-2013 Pragmatic Cohesion Consulting, LLC
6
this stage too. Finally any other known risks that can adversely impact the subsequent development phases can be recorded at this
stage.
The documented artifacts created during this phase are (21 CFR 820.30 (j)): The specification of the system context, the specification
of the system behavior (use cases and functional analysis), the Domain Model (essential Classes Diagram), and the revised risk
assessment.
Due to the strong engineering nature of this phase, software engineers are mostly responsible for conducting it. A quality assurance
role can contribute to the revision of the risk assessment document alongside software engineers.
This phase only maps strongly to the proposed software development paradigm risk management focus. No executable release comes
from this step therefore no integration is required with the non-software components of the product under development. Risk is
addressed here from a more technical standpoint by using the acquired software structural and behavioral knowledge. That knowledge
is scrutinized for potential technical risks factors related to Complexity, size, and innovative nature of the software to develop.
Design Outputs Creation Phase CFR 820.30 (d)
Design Outputs ultimately create architecture for the software system. Architecture is important for several reasons. It defines the
structure or skeleton of the software system. It is critical that the software architecture be at the right abstraction level and that it
contains sufficient generic modules that can be adapted or reused for more detailed specifications of the software functionality. The
baseline architecture therefore needs to be verified (21 CFR 820.30 (f)) to some extent to insure that it is useful and robust enough to
be the foundation of all subsequent detailed design activities. An executable architectural release does just that. It verifies that the
architecture is first functional and second comprehensive enough to remain resilient as more specific aspects of the functionality are
crafted onto it to fulfill all known software requirements. Another purpose of defining software architecture is the specification of
architectural patterns such as idioms, mechanisms, and frameworks. These patterns become standard design references for subsequent
development activities yielding cohesion of technical approaches across the entire software product.
Release planning (21 CFR 820.30 (h)) is another artifact of the design outputs phase. Since an iterative and incremental process is
used, it is necessary to specify at this stage the number of releases to be produced. Each release is characterized by the set of
requirements that it implements. Typically three to five releases can be planned. With each release, corresponding test or verification
procedures (21 CFR 820.30 (f)) are also established.

7. © 2005-2013 Pragmatic Cohesion Consulting, LLC
7
Finally a revised risk assessment (21 CFR 820.30 (e)) is conducted that takes into account any insight gained during this phase.
The documented artifacts (21 CFR 820.30 (j)) of this phase are the Executable baseline software architecture, the specification of
important architectural patterns, the release plan, the releases’ test criteria, and the revised risk assessment.
Software engineers, domain experts, and quality assurance roles are all involved in executing this phase.
Design outputs creation maps perfectly to the overall software development process paradigm. The software design itself is incarnated
into an executable baseline release. That release has to be integrated with the overall system to demonstrate its adequacy. Release
planning strategically spreads outs risks factors over several release cycles. With each cycle, new and unforeseen requirements and
issues can be identified and scheduled to be addressed in subsequent cycles without disrupting the focus of the ongoing one.
Evolution Phase
Evolution covers the release cycles established during the design outputs creation phase. Each cycle has within itself analysis, design,
implementation, and test steps leading to the release of a production quality executable. Technical risks can be tackled during
evolution by tiger teams of developers who explore on the side significant technical challenges of the software being developed (21
CFR 820.30 (e)). Tiger teams are useful to allow the main development efforts to stay on course while solutions to tricky, complex, or
very innovative aspects of the software are explored and evaluated. Tiger teams create risks exploration prototypes. A suggested
distribution of development efforts between the main activities and the tiger team ones could be respectively 80% and 20%.
Software testing (verification and validation) (21 CFR 820.30 (f and g)) is performed here. With each release cycle, newly created
modules are tested and integrated to the existing code. A comprehensive regression test is also done to ensure that the desired
functionality captured by the previous release has not been disrupted by newly added features.
Many documents are created and updated during this phase (21 CFR 820.30 (j)). Software Requirements, Design, Implementation,
Deployment, Testing (Verification and Validation), and User Guide documents are generated and updated as release cycles are
executed.
Software engineers, domain experts, and quality assurance roles are all involved in executing the Evolution phase.

8. © 2005-2013 Pragmatic Cohesion Consulting, LLC
8
Evolution is the embodiment of the proposed software development process paradigm. Fully functional and integrated software
releases are generated. Incremental delivery of software functionality is achieved with each release. Project management visibility of
the project status and quality is made explicit and frequent at the conclusion of each release cycle. Risks handling measures can be
therefore scheduled for subsequent release cycles.
The following table presents the detail planning for each phase by spelling out Phases activities, artifacts, actors, and milestones (21
CFR 820.30 (b)).
Phase Activities Artifacts Actors Duration Milestones
Conceptualization Build a proof of
concept
Executable prototype -Software
Engineer
1/12 Executable prototype
Use prototype to
evaluate
potential sources
of risks
Risk Assessment -Software
Engineer
-Users
-Domain experts
Define General
vision of
Requirements
General vision of
Requirements
-Users
-Domain experts
Design Inputs
Creation
Identify system
boundaries
Description of the system
context
-Software
Engineer
[1/12-2/12] specification of the
system context
(evolving document)
Create Use Cases
and Message
trace diagrams
Scenarios describing the
system behavior
-Software
Engineer
specification of the
system behavior
(evolving document)
Create essential
classes diagram
Domain Model -Software
Engineer
Specification Domain
Model
(evolving document)

9. © 2005-2013 Pragmatic Cohesion Consulting, LLC
9
Phase Activities Artifacts Actors Duration Milestones
Identify the
known technical
and non technical
areas risk that
might impact the
design process
Revisited risk assessment -Software
Engineer
-Quality
assurance
Revisited risk
assessment
Design Outputs
Creation
Develop an
executable
architecture that
contains reusable
artifacts
Executable and baselined
architecture
-Software
Engineer
1/12 Executable
architectural release
Perform
Architectural
planning
Specification of all
important architectural
patterns (Idioms,
mechanisms, frameworks)
-Domain Experts
-Software
Engineer
Prototypes and
documentation of the
system’s major
patterns
Perform Release
planning
Release plan (3-5
releases)
-Domain Experts
-Software
Engineer
-Quality
Assurance
Acceptance of the
release plan
Test Criteria
Revised risk assessment
Evolution Micro process
cycles of
analysis, design
and
implementation
Incremental Executable
Releases
-Principal
developers
-Software
Engineer
(80% dev
resource)
9/12 Deployable Executable
Releases

10. © 2005-2013 Pragmatic Cohesion Consulting, LLC
10
Phase Activities Artifacts Actors Duration Milestones
Risk exploration
prototypes
-Tiger team
developers
-Software
Engineer
(20% dev
resource)
User documentation
Documentation tracking
micro process activities of
analysis, design and
implementation
-All developers
-Software
Engineer
Internal Design history
documentation
Unit testing of
new modules and
Regression
Testing of each
release
Tests documentation -Domain Experts
-Quality
Assurance
Test results document

11. © 2005-2013 Pragmatic Cohesion Consulting, LLC
11
Contact Pragmatic Cohesion Consulting to get advice on implementing
FDA 21CFR 820.30 Compliant Software Development Processes
In your Organization
http://pragmaticohesion.com/