• Save
Fda 21 CFR 820.30 compliant software development process
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Fda 21 CFR 820.30 compliant software development process

on

  • 3,692 views

Biomedical engineering work is subjected to stringent regulatory constraints that mandate a robust engineering process that conforms to all pertinent regulatory guidelines and imperatives.

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.

Statistics

Views

Total Views
3,692
Views on SlideShare
3,454
Embed Views
238

Actions

Likes
1
Downloads
29
Comments
0

8 Embeds 238

http://pragmaticohesion.com 154
http://www.pragmaticohesion.com 43
https://app7.websitetonight.com 17
http://app6.websitetonight.com 14
http://www.linkedin.com 6
http://app5.websitetonight.com 2
http://www.slideshare.net 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fda 21 CFR 820.30 compliant software development process Presentation Transcript

  • 1. © 2005-2013 Pragmatic Cohesion Consulting, LLC1A Potential FDA 21 CRF 820.30 CompliantSoftware Development ProcessFor Innovative Biomedical IndustriesInspired by Grady Booch – Object Solutions
  • 2. © 2005-2013 Pragmatic Cohesion Consulting, LLC21 The Software Development Process1.1 Motivation for an improved software development process in Innovative Biomedical IndustriesBiomedical engineering work is subjected to stringent regulatory constraints that mandate a robust engineering process that conformsto 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 properlyintegrated with the overall engineering process. To that effect, the following software development process is proposed. This processattempts to be well grounded in the nature of innovative Biomedical engineering work. For example, many innovative biomedicalproducts go through several successive needed refinements that initially explore the device concept and progressively yield moremature and robust systems that meet FDA regulatory requirements. There are inherent significant technology risks related to thedevelopment of innovative biomedical devices. These risks must be correctly identified, and mitigated throughout the entireengineering process. The main benefit of the software development process presented here is its explicit management of software riskfactors as recommended by modern successful software development practices. This process also promotes the regular delivery oftangible design history artifacts. The following three driving factors capture the essence of the proposed software developmentprocess: Continuous Integration of software components and software with hardware components. The goal is to facilitate the detectionof 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 inthe ongoing development efforts. Also newly discovered issues can be scheduled to be addressed in future releases as opposedto disrupting the current release ongoing efforts. Promote management visibility on project progress and quality. By making executable releases and their associated artifactsmilestones, management can tangibly access quality and also identify and mitigate risk factorsThe 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, LLC31.2 Major Software Development PhasesThe 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 acommon vocabulary and a common understanding of the systems’ desired behavior by exploring scenarios with end users anddomain experts. Design Outputs Creation (Design) creates the software architecture. It establishes a skeleton for the solution and lay downtactical policies for implementation by drafting the system’s architecture Evolution evolves and deploys the implemented software through successive refinements. It is characterized by severalpackage 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 ActivitiesConceptualization Establish core requirements Bracket the project’s risks by building a proof of conceptDesign InputsCreation - CFR820.30 (c)Develop a model for the software systemdesired behaviorDevelop a common vocabulary and a common understandingof the system’s desired behavior by exploring scenarios withend users and domain expertsDesign OutputsCreation –CFR820.30 (d)Create an architecture for the implementation Establish a skeleton for the solution and lay down tacticalpolicies for implementation by drafting the system’sarchitectureEvolution Evolve and deploy the implementationthrough successive refinementsRefine the architecture and package releases for deployment;further analysis, design, and implementation neededMaintenance Manage post-delivery evolution Continue the system refinement to address newly identifiedrequirementsIn 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, LLC42-Phases Detail DescriptionConceptualization PhaseThe conceptualization phase is very exploratory in nature. The development team and the potential users try to establish a proof ofconcept for the software to be built. The creation of an executable prototype is favored for several reasons. First of all an executableprototype is executable i.e. it is a functional software that contains many critical features. By being a tangible artifact, an executableprototype gives the user community an opportunity to provide more accurate assessments of the perceived capabilities of the prototypesoftware. It is important to realize that the prototype aims only at proving the software concept; it is in no way a production qualityrelease. The prototype must be seen as a risk exploration tool that boldly tackles the most important software risk factors as they relateto the overall product functionality. Because other engineering areas of the system (mechanical, electronics) are very likely to be alsogoing through this early conceptualization phase, the prototype software should ultimately demonstrate a proper fit in the overallintegrated prototype system. By emphasizing the creation of an integrated prototype system, obvious risks factors can be identified atthe software level or at the software/system integration level. A general vision of requirements is created during this stage in aninteractive manner by exposing the user community to the prototype system. With direct exposure to a tangible product, userrequirements 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 componentsand 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 inthe 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 thisdocument. The integration of software with the rest of the system is achieved with the integrated prototype system, the idea ofincremental refinements and delivery of executables is established with the executable prototype which represents the first incarnationof a series of releases that will grow in functionality and completeness as the project unfolds. Management visibility on risks factors ismade explicit with the creation of the software components and software components integration risk assessment document. With thatdocument in its hands, management possesses tangible material for defining a pertinent software risk management plan that will bereassessed and executed as the project progresses.
  • 5. © 2005-2013 Pragmatic Cohesion Consulting, LLC5The 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 exampleof such documents. It clearly spells out the boundaries of the software system under creation as it relates to external systems’ softwareand non-software components. This document takes the shape of a list of inputs and outputs into and out of the software system. Italso 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 thesoftware system desired behavior from the standpoint of a user. Use cases resemble scenario descriptions of user interactions with thesystem 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 functionsof the system to discover the behavior embedded in it. That analysis strongly depends on the initial formulation of various scenariosdescribing from a user standpoint what services might be needed from the system. Performing functional analysis reveals someimplied requirements that are not explicitly stated in the originating user requirements and that are discovered by a decomposition andclassification exercise. Inputs and outputs become valuable instruments to capture the interaction taking place between functions andsub-functions in terms of data, material, or energy transformed or transported within the system and between the system and itsenvironment. 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. Thisallocation 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 arealso identified in these diagrams. The set of essential classes and their inter relationships constitute the Domain Model. The DomainModel is an evolving artifact that gets refined as more knowledge about the system is gathered throughout the project life cycle. At theanalysis 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 identifiedby the analysis work performed up to that point. Size, complexity, and innovative nature of the software can be better assessed at thispoint. 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, LLC6this stage too. Finally any other known risks that can adversely impact the subsequent development phases can be recorded at thisstage.The documented artifacts created during this phase are (21 CFR 820.30 (j)): The specification of the system context, the specificationof the system behavior (use cases and functional analysis), the Domain Model (essential Classes Diagram), and the revised riskassessment.Due to the strong engineering nature of this phase, software engineers are mostly responsible for conducting it. A quality assurancerole 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 comesfrom this step therefore no integration is required with the non-software components of the product under development. Risk isaddressed here from a more technical standpoint by using the acquired software structural and behavioral knowledge. That knowledgeis 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 thestructure or skeleton of the software system. It is critical that the software architecture be at the right abstraction level and that itcontains sufficient generic modules that can be adapted or reused for more detailed specifications of the software functionality. Thebaseline architecture therefore needs to be verified (21 CFR 820.30 (f)) to some extent to insure that it is useful and robust enough tobe the foundation of all subsequent detailed design activities. An executable architectural release does just that. It verifies that thearchitecture is first functional and second comprehensive enough to remain resilient as more specific aspects of the functionality arecrafted onto it to fulfill all known software requirements. Another purpose of defining software architecture is the specification ofarchitectural patterns such as idioms, mechanisms, and frameworks. These patterns become standard design references for subsequentdevelopment 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 isused, it is necessary to specify at this stage the number of releases to be produced. Each release is characterized by the set ofrequirements that it implements. Typically three to five releases can be planned. With each release, corresponding test or verificationprocedures (21 CFR 820.30 (f)) are also established.
  • 7. © 2005-2013 Pragmatic Cohesion Consulting, LLC7Finally 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 ofimportant 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 incarnatedinto an executable baseline release. That release has to be integrated with the overall system to demonstrate its adequacy. Releaseplanning strategically spreads outs risks factors over several release cycles. With each cycle, new and unforeseen requirements andissues can be identified and scheduled to be addressed in subsequent cycles without disrupting the focus of the ongoing one.Evolution PhaseEvolution 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 duringevolution by tiger teams of developers who explore on the side significant technical challenges of the software being developed (21CFR 820.30 (e)). Tiger teams are useful to allow the main development efforts to stay on course while solutions to tricky, complex, orvery innovative aspects of the software are explored and evaluated. Tiger teams create risks exploration prototypes. A suggesteddistribution 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 createdmodules are tested and integrated to the existing code. A comprehensive regression test is also done to ensure that the desiredfunctionality 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 areexecuted.Software engineers, domain experts, and quality assurance roles are all involved in executing the Evolution phase.
  • 8. © 2005-2013 Pragmatic Cohesion Consulting, LLC8Evolution is the embodiment of the proposed software development process paradigm. Fully functional and integrated softwarereleases are generated. Incremental delivery of software functionality is achieved with each release. Project management visibility ofthe project status and quality is made explicit and frequent at the conclusion of each release cycle. Risks handling measures can betherefore scheduled for subsequent release cycles.The following table presents the detail planning for each phase by spelling out Phases activities, artifacts, actors, and milestones (21CFR 820.30 (b)).Phase Activities Artifacts Actors Duration MilestonesConceptualization Build a proof ofconceptExecutable prototype -SoftwareEngineer1/12 Executable prototypeUse prototype toevaluatepotential sourcesof risksRisk Assessment -SoftwareEngineer-Users-Domain expertsDefine Generalvision ofRequirementsGeneral vision ofRequirements-Users-Domain expertsDesign InputsCreationIdentify systemboundariesDescription of the systemcontext-SoftwareEngineer[1/12-2/12] specification of thesystem context(evolving document)Create Use Casesand Messagetrace diagramsScenarios describing thesystem behavior-SoftwareEngineerspecification of thesystem behavior(evolving document)Create essentialclasses diagramDomain Model -SoftwareEngineerSpecification DomainModel(evolving document)
  • 9. © 2005-2013 Pragmatic Cohesion Consulting, LLC9Phase Activities Artifacts Actors Duration MilestonesIdentify theknown technicaland non technicalareas risk thatmight impact thedesign processRevisited risk assessment -SoftwareEngineer-QualityassuranceRevisited riskassessmentDesign OutputsCreationDevelop anexecutablearchitecture thatcontains reusableartifactsExecutable and baselinedarchitecture-SoftwareEngineer1/12 Executablearchitectural releasePerformArchitecturalplanningSpecification of allimportant architecturalpatterns (Idioms,mechanisms, frameworks)-Domain Experts-SoftwareEngineerPrototypes anddocumentation of thesystem’s majorpatternsPerform ReleaseplanningRelease plan (3-5releases)-Domain Experts-SoftwareEngineer-QualityAssuranceAcceptance of therelease planTest CriteriaRevised risk assessmentEvolution Micro processcycles ofanalysis, designandimplementationIncremental ExecutableReleases-Principaldevelopers-SoftwareEngineer(80% devresource)9/12 Deployable ExecutableReleases
  • 10. © 2005-2013 Pragmatic Cohesion Consulting, LLC10Phase Activities Artifacts Actors Duration MilestonesRisk explorationprototypes-Tiger teamdevelopers-SoftwareEngineer(20% devresource)User documentationDocumentation trackingmicro process activities ofanalysis, design andimplementation-All developers-SoftwareEngineerInternal Design historydocumentationUnit testing ofnew modules andRegressionTesting of eachreleaseTests documentation -Domain Experts-QualityAssuranceTest results document
  • 11. © 2005-2013 Pragmatic Cohesion Consulting, LLC11Contact Pragmatic Cohesion Consulting to get advice on implementingFDA 21CFR 820.30 Compliant Software Development ProcessesIn your Organizationhttp://pragmaticohesion.com/