![BEHAVIOR DRIVEN DEVELOPMENT
(BDD)
orthogonal.ioAgile in a QMS27
“Behavior-driven development is an
“outside-in” methodology. It starts at
the outside by identifying business
outcomes, and then drills down into
the feature set that will achieve those
outcomes. Each feature is captured as
a “story”, which defines the scope of
the feature along with its acceptance
criteria.”
• —Dan North
Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
Scenario 2: ...](https://image.slidesharecdn.com/agiled-medical-software-161201214445/75/Agile-in-Medical-Software-Development-27-2048.jpg)
Uploaded byBernhard Kappe
Agile in Medical Software Development
The document presents a comprehensive overview of how medical device companies can adopt agile methodologies in their Quality Management Systems (QMS). It discusses the benefits, challenges, and implementation strategies for integrating agile practices, emphasizing iterative risk management, verification and validation processes, and the importance of continuous feedback. Key factors for successful agile deployment include addressing regulatory complexities and ensuring the adaptation of agile principles in the context of medical device standards.
More Related Content
Similar to Agile in Medical Software Development
Agile in Medical Software Development
- 1. O R TH O G O N A L orthogonal.io A G I L E I N A Q M S What Medical Device Companies Need to Know
- 2. PRESENTATION AGENDA orthogonal.ioAgile ina QMS2 Background Agile Introduction Agile for Medical Devices How to be Agile in a QMS Automation How to be Agile in a QMS (for Non Developers) Agile Implementation Mistakes Resources
- 3. I N TR O D U C T I O N Background on Bernhard and Orthogonal orthogonal.ioAgile in a QMS3
- 4. ABOUT ME 4 Agilein a QMS orthogonal.io Bernhard Kappe CHIEF EXECUTIVE OFFICER, ORTHOGONAL Bernhard is an expert in lean innovation and the application of agile methods in regulated industries. He is the author of the eBook Agile in an FDA Regulated Environment and a frequent conference speaker on wireless medical devices and mHealth. He works with Orthogonal clients on connected care strategy and at the application of lean and agile methods.
- 5. orthogonal.ioAgile in aQMS5 CONNECTED CARE TECHNOLOGIES
- 6.
- 7. A G IL E I N F I V E M I N U T E S A Quick recap of the why and what of Agile orthogonal.ioAgile in a QMS7
- 8. CLASSIC WATERFALL 8 Works greatwhen problems and solutions are well known!
- 9. THE COST OFCHANGE IN WATERFALL 9
- 10. ITERATIVE METHODS Fast FeedbackLoops to Reduce Uncertainty and Efficiently Manage Change: • OODA Loops • Shewhart/Deming Cycles (PDCA) • Six Sigma (DMAIC) • Toyota Production System • Lean Manufacturing • Lean Startup • Lean UX orthogonal.ioAgile in a QMS10
- 11. AGILE APPROACH orthogonal.ioAgile in aQMS11 • Break functionality into the smallest units of customer value: the user story. • Organize the stories into a prioritized list called a backlog • Organize development efforts into short (one to two week0 efforts called iterations or sprints. • The goal of each iteration: Demonstrate working software • Take feedback and improve the process through retrospectives and the software through refactoring. • Self Organizing Teams
- 12. AGILE ITERATIONS 12 • StoryBaking – Detailed specification of user stories, including acceptance criteria and ties to FURPS+. • Story Points – Unit of estimation measuring complexity and size. • Iteration Planning Meeting – a negotiation between the team and the product owner about what the team will do during the next Iteration. The product owner and all team members agree on a set of Iteration goals, which are used to determine which product backlog items to commit from the uncommitted backlog to the Iteration. Often new backlog items are defined during the meeting. • Daily Standup Meeting - a 10-minute daily meeting for the team • Pair Programming – two programmers work together on one user story. • Test Driven Development (TDD) – repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. • Continuous Integration – code is checked into a continuous integration environment/build server, which runs automated tests (unit, integration, static and dynamic analysis, etc.) • Demo/Design Review - On a per iteration basis, functional software is reviewed by stakeholders, including source code review • Retrospective - what went well and what to improve in the next Iteration.
- 13. THE COST OFCHANGE CURVE REVISITED 13
- 14. THE COST OFCHANGE CURVE REVISITED 14
- 15. A G IL E F O R M E D I C A L D E V I C E S Why we need Agile and why it’s taken so long to adopt it orthogonal.ioAgile in a QMS15
- 16. CHANGE AND UNCERTAINTY •New Product Development • Complex Systems • System Interdependencies • More Users • Technology Changes • Market Changes • Regulatory Changes orthogonal.ioAgile in a QMS16
- 17. orthogonal.ioAgile in aQMS17 MEDICAL DEVICE CHALLENGES The Target Business Value/ Real-World Outcomes Patient Safety Process Efficiency Regulatory Compliance
- 18. BARRIERS TO AGILE •Agile evolved in software, and Medical Devices used to not have much software. • Regulations, standards and guidance documents (CFR 21 Part 820, ISO 13485, IEC 62304) were mostly defined before agile, and are written in a waterfall way. • Medical Device regulations and standards have additional requirements (risk management, design controls, verification and validation) that add complexity to Agile. orthogonal.ioAgile in a QMS18
- 19. THE FDA DESCRIBESRATHER THAN PRESCRIBES “The quality system requirements do not dictate the types of design process that a manufacturer must use. Manufacturers should use processes best suited to their needs. However, whatever the processes may be, it is important that the design controls are applied in an appropriate manner.” FDA Design Control Guidance for Medical Device Manufacturers, p. 8 “Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.” General Principles of Software Validation (GPSV), p. 1 orthogonal.ioAgile in a QMS19
- 20. RESOURCES: AAMI TIR45:2012 •Provides recommendations for complying with international standards and FDA guidance documents when using agile practices to develop medical device software. • Agile brings value to medical device software: continuous focus on safety, risk management and control, impact analyses, . . . • Designs coherent (locally constant) and highly cohesive (vs. tightly coupled) • Recognized as a standard by the FDA in 2013 20
- 21. H O WT O B E A G I L E I N A Q M S Mapping Agile to IEC 62304 and CFR 21 Part 820 orthogonal.ioAgile in a QMS21
- 22. APPLYING AGILE UNDERTHE QSR • Mapping agile (TIR 45) to IEC 62304 • Layering in: Risk Analysis, Design review, etc • Verification Driven Development Testing Automation 22
- 23. IEC 62304: MEDICALDEVICE SOFTWARE LIFECYCLE PROCESSES 23 8. Software Configuration Management 9. Software Problem Resolution 7. Software Risk Management 5. Software Development Process 5.2 SW Requirements Analysis 5.3 SW Architectural Design 5.4 SW Detailed Design 5.7 SW System Testing 5.8 SW Release 5.1 SW Development Planning 5.5 SW Unit Implement. & Verification 5.6 SW Integration & Integration Testing
- 24.
- 25. FDA DESIGN CONTROLSGUIDANCE Footer Text25
- 26. V-MODEL: BENT WATERFALLOR AGILE? orthogonal.ioAgile in a QMS26 User Requirements System Requirements Specification Software Detailed Design User Acceptance Testing System & Integration Testing Unit Testing Quality Assurance / Risk Control • Relationship between artifacts are time- independent • Finish to finish parallelism (vs. start to finish) • Design Inputs ↔ Design Outputs • Synchronize Approvals
- 27. BEHAVIOR DRIVEN DEVELOPMENT (BDD) orthogonal.ioAgilein a QMS27 “Behavior-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria.” • —Dan North Title (one line describing the story) Narrative: As a [role] I want [feature] So that [benefit] Acceptance Criteria: (presented as Scenarios) Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Scenario 2: ...
- 28. VERIFICATION DRIVEN AGILE orthogonal.ioAgilein a QMS28 Verification Test • Avoids different interpretations of requirements and specification that are typical in waterfall development • This avoids “verification hell” that can double the length and cost of a project. • Allows for continued feedback from end users on working software – further reducing risk
- 29. R I SK M A N A G E M E N T I N A G I L E It’s Iterative orthogonal.ioAgile in a QMS29
- 30. THE ITERATIVE NATUREOF RISK orthogonal.ioAgile in a QMS30 “Risk can be introduced throughout the product lifecycle, and risks that become apparent at one point in the life-cycle can be managed by action taken at a completely different point in the life cycle.” ISO 14971: 2007 Medical devices -- Application of risk management to medical devices
- 31. orthogonal.ioAgile in aQMS31 ITERATIVE RISK MANAGEMENT • Iterative Risk Analysis Takes inputs from and provides outputs to Human Factors and Development • Risk Mitigations are reflected in new stories. • Risk Mitigations are verified and validated • The Iterative Risk Management cadence can be different than the development cadence
- 32. HUMAN FACTORS ENGINEERING orthogonal.ioAgile ina QMS32 • Lean and agile cadence ships insights and/or UI each iteration • User experience architecture maps and assesses human interaction models and requirements • Usability studies conducted with real users to identify and assess the effectiveness of vital system interactions • Interactive prototypes to simulate interactive functions of the software • User interface design of software interface using color, animation, text and graphics • Result: – User Engagement – Real-World Outcomes
- 33. A U TO M A T I O N The key to maintaining quality at speed orthogonal.ioAgile in a QMS33
- 34. TDD+ BDD +TESTING AUTOMATION 34 From this: … to this
- 35. TESTING AUTOMATION • FullCode Coverage: Unit, Integration, Acceptance Testing built into continuous integration environment. • White-box and black-box testing for all elements of the stack, from hardware to firmware to web services • Result: – Maintain Velocity on Larger, More Complex Projects – Faster Parallel Development of Hardware and Software – Faster, More Efficient Maintenance orthogonal.ioAgile in a QMS35
- 36. AGILE DESIGN CONTROLS orthogonal.ioAgilein a QMS36
- 37.
- 38. AGILE ITERATION ANDDOCUMENTATION
- 39. H O WT O B E A G I L E I N A Q M S ( F O R N O N - D E V E L O P E R S ) A selection of connected care solutions Orthogonal has developed for the medical industry. orthogonal.ioAgile in a QMS39
- 40.
- 41. orthogonal.ioAgile in aQMS41 Agile development is wasted If none of the related processes can iteratively provide and receive input. Risk Managment Human Factors Verification & Validation Post Market Surveillance Product Managment Document Managment
- 42.
- 43. PUTTING IT ALLTOGETHER orthogonal.ioAgile in a QMS43 Business Value/ Real-World Outcomes Patient Safety Process Efficiency Regulatory Compliance Better usability, adherence/compliance = Improved Engagement and Outcomes Iterative Risk Management = Safer Products and Reduced Regulatory Risk Faster Development Streamlined Maintenance and Manufacturing Platform Development/Reusability
- 44. A G IL E I M P L E M E N TAT I O N M I S T A K E S A selection of connected care solutions Orthogonal has developed for the medical industry. orthogonal.ioAgile in a QMS44
- 45. orthogonal.ioCompany Overview45 Area Finding(Gap) Best Practice Consequences of Gap Recommended Approach Dependencies Quality Management Development Methodology and Quality Management System (QMS) are Tightly Coupled Loose Coupling of Quality Management and Development Approach. Changes in development methodology as needed by individual projects may result in changes and re-approvals of parts of the QMS which takes time and consumes significant organizational resources Allow for different development methodologies by stating in QMS that any methodology based on a standard and that meets relevant regulations is allowed as long as it is approved by Quality. Consider templated approach at SDP level. Approvers of QMS (Executive management, Quality, Regulatory) Risk Management Risk Management is not iterative and integrated into agile process QMS states that Risk Management Plan determines how risk control is performed throughout the product lifecycle. Risk Management that is not iterative and integrated into agile process may result in an "Agile Falls" lifecycle where risk "in-stream" risk analysis and mitigation suffers and risk management activities become a bottleneck for other project activities to continue QMS does not specify risk management methodology, only that risk control activities will be performed throughout the project lifecycle as required by relevant regulations. Risk Management Plan outlines risk control activities and their rationales on a per project basis. QMS Risk Management Process. Verification and Validation Verification and Validation (VnV) is not iterative and integrated into agile process QMS states that Validation Plan determines how VnV is performed throughout the product lifecycle VnV that is not iterative and integrated into agile process may result in an "Agile Falls" lifecycle where verification testing fails to indicate when an issue appears and VnV activities become a bottleneck for other project activities to continue. QMS includes a VnV process definition that is iterative and can be integrated into agile processes. QMS Verification And Validation Process. Requirements Management Requirements PRDs do not incorporate Agile User Stories Include "story points" in User Stories as user requirements User requirements may miss important user requirements Include "story points" in User Stories as user requirements. Also consider using Human Factors Engineering and Stakeholder (e.g. clinician and patient) flow analyses as a way of logically grouping User Stories. QMS Requirements Management Process Requirements Management Inadequate Software Tools for Requirements Management and Traceability Analyze and determine which tools for Requirements Management and Traceability would best fit the organization. Poorly specified requirements, inadequate traceability; inability to analyze logically categorize requirements Follow recommendation for which tools to use for Requirements Management and Traceability that would best fit the organization QMS Testing Automation No unit or integration tests Implement a "test first" approach to Unit Tests when specifying low level requirements (i.e. how would this requirement be tested?). Poorly specified and tested requirements. Automate unit and integration testing in a Continuous Integration Environment QMS Test Plan, Tools Validation Testing Automation No Continuous Integration Environment Specify interface requirements and sub-system integration tests during system development. Poorly specified and tested requirements. Automate Continuous Integration Environment; justify when able to do so. QMS Test Plan, Tools Validation Testing Automation No Acceptance tests Specify user acceptance tests when constructing User Requirements. Poorly specified and tested requirements. Automate acceptance testing (as reasonably possible) QMS Test Plan, Tools Validation, Continuous Integration Environment Acceptance test automation
- 46. #1: TIGHT COUPLING Finding:Development Methodology and Quality Management System (QMS) are Tightly Coupled Consequences: Constraints on Implementing Agile. Changes in development methodology as needed by individual projects may result in changes and re-approvals of parts of the QMS which takes time and consumes significant organizational resources. Best Practice: Loose Coupling of Quality Management and Development Approach. Recommended Approach: Allow for different development methodologies by stating in QMS that any methodology based on a standard and that meets relevant regulations is allowed as long as it is approved by Quality. Consider templated approach at SDP level. Dependencies: Approvers of QMS (Executive management, Quality, Regulatory) orthogonal.ioAgile in a QMS46
- 47. #2: WATERFALL RISKMANAGEMENT Finding: Risk Management is not iterative and integrated into agile process Consequences: Risk Management that is not iterative and integrated into agile process may result in an "Agile Falls" lifecycle where risk "in-stream" risk analysis and mitigation suffers and risk management activities become a bottleneck for other project activities to continue Best Practice: QMS states that Risk Management Plan determines how risk control is performed throughout the product lifecycle. Recommended Approach: QMS does not specify risk management methodology, only that risk control activities will be performed throughout the project lifecycle as required by relevant regulations. Risk Management Plan outlines risk control activities and their rationales on a per project basis. Dependencies: QMS Risk Management Process. orthogonal.ioAgile in a QMS47
- 48. #3: V&V NOTINTEGRATED Finding: Verification and Validation (V&V) is not iterative and integrated into agile process Consequences: V&V that is not iterative and integrated into agile process may result in an "Agile Falls" lifecycle where verification testing fails to indicate when an issue appears and V&V activities become a bottleneck for other project activities to continue. Best Practice: QMS states that Validation Plan determines how V&V is performed throughout the product lifecycle. Recommended Approach: QMS includes a V&V process definition that is iterative and can be integrated into agile processes. Dependencies: QMS Verification And Validation Process orthogonal.ioAgile in a QMS48
- 49. #4: NO USERSTORIES IN THE PRD Finding: Product Requirement Documents do not incorporate Agile User Stories Consequences: Requirements may miss important user requirements, and require additional translation to agile-usable requirements Best Practice: Include story definitions in User Stories as user requirements Recommended Approach: Include story definitions in User Stories as user requirements. Also consider using Human Factors Engineering and Stakeholder (e.g. clinician and patient) flow analyses as a way of logically grouping User Stories. Dependencies: QMS Requirements Management Process orthogonal.ioAgile in a QMS49
- 50. #5: NO AGILERM TOOLS Finding: Inadequate Software Tools for Requirements Management and Traceability Consequences: Poorly specified requirements, inadequate traceability; inability to analyze logically categorize requirements, lots of extra work. Best Practice: Analyze and determine which tools for Requirements Management and Traceability would best fit the organization. Recommended Approach: Follow recommendation for which tools to use for Requirements Management and Traceability that would best fit the organization Dependencies: QMS, Tools Validation orthogonal.ioAgile in a QMS50
- 51. #6: NO TDDOR BDD Finding: No or insufficient unit, integration and acceptance test coverage. Consequences: Poorly specified and tested requirements. Bugs, more laborious maintenance Best Practice: Implement a "test first" approach to Unit Tests, Integration Tests and Acceptance tests when specifying requirements (i.e. how would this requirement be tested?). Recommended Approach: TDD and BDD, Automate unit, integration and acceptance testing in a Continuous Integration Environment Dependencies: QMS Test Plan, Tools Validation orthogonal.ioAgile in a QMS51
- 52. #7: NO PAIRING Finding:No Developer Pairing Consequences: Slower development, greater dependency on individual developers (lower “bus number”), no built-in design review, less ability to scale projects up and down, higher training costs Best Practice: Implement Promiscuous Pairing. Recommended Approach: Training and Mentoring by developers experienced with pairing. Dependencies: Developers who can pair orthogonal.ioAgile in a QMS52
- 53. R E SO U R C E S A selection of connected care solutions Orthogonal has developed for the medical industry. orthogonal.ioAgile in a QMS53
- 54. RESOURCES: AAMI TIR45:2012 •Provides recommendations for complying with international standards and FDA guidance documents when using agile practices to develop medical device software. • Agile brings value to medical device software: continuous focus on safety, risk management and control, impact analyses, . . . • Designs coherent (locally constant) and highly cohesive (vs. tightly coupled) • Recognized as a standard by the FDA in 2013 54
- 55. RESOURCES: ORTHOGONAL EBOOK • Addressesthe shortcomings of waterfall development specifically in regulatory environments. • How agile development meets the safety, reliability and regulatory needs of the medical device and diagnostics industry. • How agile development can help ensure delivery of successful software. 55
- 56. Q U ES T I O N S ? Bernhard Kappe bkappe@orthogonal.io orthogonal.ioAgile in a QMS56
- 57.
Editor's Notes
- #6 We build everything except the devices and the firmware. Connectivity, mobile, web, cloud, integration to midleware for clinical systems.
- #9 Look at traditional waterfall development process – how we used to do everything, including software. This works great when problems and solutions are well known.
- #10 But if not, if you have changes – it gets expensive quickly, because you have to go all the way back and make changes to everything else. Change is inevitable, and there are many unknown things.
- #11 There’s another set of approaches, which is based on fast feedback loops to address change. All based on a build-measure-learn loop and making adjustments. From military Observe, Orient, Decide and Act. – if your OODA loop is faster, you increase your chances of winning. All are about Feedback
- #12 Agile applies this to software development. Agile does not attempt to lock down all requirements up front. It assumes that the requirements and design will evolve and change as more is learned and discovered during the process. It works by breaking projects down into user stories - little bits of user functionality that create value for the user - prioritizing them, continuously delivering them in short one to three week cycles called iterations, and getting feedback on the working software to incorporate back into the development process.
- #17 This is a more complex system, with more moving parts, and more things that can go wrong: hardware, software stack, integrations, data and algorithms. There are a lot of dependencies there. Integrations are points of failure * Data loss, distributed systems, transmission Latency can be a problem - example – neurostimulation implant used for accelerating stroke rehab. Button pressed by clinician. There was unanticipated lag in the wireless transmission. Had to do a whole new animal trial to see if the lag time was clinically important. If you have connected systems, you have security risks and privacy risks. HIPAA compliance includes security and privacy considerations. You also need to think about business associates agreements. This also includes any analytics. Google analytics, others not. Need this. FDA has cybersecurity guidance documents – others have talked about this at the conference in much more detail. They’ve put in place a lab for fuzz testing, will be a greater point of emphasis If some of what you need to do involves apps in app stores – be careful which ones you put them in, because what comes out may not be what you put in. One of our clients asked us to run a test on this for android app stores. We built and submitted a very small app in such a way that it was easy to reverse engineer what the app stores did to them. I can’t really name names here, but in some cases it was harmless. In others they put a lot of extra things into the apps. Complex systems with lots of moving parts. Devices, sensors, diagnostics, mobile, back end systems, integrations. Some of these are changing quickly. Users are tricky. If you remember that we’re all wireless that adds more complexity – there are more users of the systems than you think – potentially clinicians, technicians, patients, caregivers, etc. For patients – don’t have training, depending on patients, very varied abilities and knowledge. Children, elderly, etc. Real world issues. Not just use error, but usability important (EU, need to take that into consideration.) Real World Issues are what’s important here.
- #18 Do this in a complex, rapidly changing enviroment
- #20 FDA does not dictate process. It describes but does not prescribe.
- #26 One of the biggest things that trips people up is this old graph from the 1970’s that’s still in the FDA guidance.
- #27 Time independence. Finish to finish parallelism.
- #28 Stories – requirements. Acceptance Criteria: Specification. Acceptance Tests: Verification Protocols BDD drives validation. Lose sight of intended use.
- #29 Stories – requirements. Acceptance Criteria: Specification. Acceptance Tests: Verification Protocols BDD drives validation. Lose sight of intended use.
- #31 FDA does not dictate process. It describes but does not prescribe.
- #32 Risk management core to the process Collaborative with our clients – risk evaluation Responsive to inputs Safer!
- #35 tw
- #36 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #37 Tooling to manage the process, lightweight, manage agile requirements, traceability, hazard analysis, and documentation
- #38 How do we build successful connected care products? By making complex systems simple and elegant. Our process is designed from the ground up to address complexity, uncertainty and change. Here's how we help you accelerate the development of successful products: DESIGN Simplifying complexity starts with a deep understanding of unmet human needs. These insights drive design solutions we iteratively prototype and test, and result in artifacts that clearly communicate to agile developers so they can efficiently realize the design. TECHNOLOGY We've done this before. That means we understand devices, wireless and bluetooth protocols, cloud computing and clinical systems and how they interact. That let's us think ahead and apply a systems engineering approach to minimize surprises and technical risk. AGILITY + QUALITY Our quality processes integrate risk management, verification and validation. By eliminating the waste inherent in waterfall processes we accelerate development while improving quality. Our processes are in line with ISO 13485 and IEC 62304 standards and AAMI TIR:45. TESTING AUTOMATION Testing automation is core to managing complexity and quality at speed. For us that means automated system-level verification and validation testing, including black-box and white-box testing of hardware, software and interfaces. This enables accelerated development and maintenance.
- #39 How do we build successful connected care products? By making complex systems simple and elegant. Our process is designed from the ground up to address complexity, uncertainty and change. Here's how we help you accelerate the development of successful products: DESIGN Simplifying complexity starts with a deep understanding of unmet human needs. These insights drive design solutions we iteratively prototype and test, and result in artifacts that clearly communicate to agile developers so they can efficiently realize the design. TECHNOLOGY We've done this before. That means we understand devices, wireless and bluetooth protocols, cloud computing and clinical systems and how they interact. That let's us think ahead and apply a systems engineering approach to minimize surprises and technical risk. AGILITY + QUALITY Our quality processes integrate risk management, verification and validation. By eliminating the waste inherent in waterfall processes we accelerate development while improving quality. Our processes are in line with ISO 13485 and IEC 62304 standards and AAMI TIR:45. TESTING AUTOMATION Testing automation is core to managing complexity and quality at speed. For us that means automated system-level verification and validation testing, including black-box and white-box testing of hardware, software and interfaces. This enables accelerated development and maintenance.
- #47 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #48 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #49 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #50 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #51 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #52 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #53 Underlying mobile and cloud platforms change in weeks and months. Maintenance using manual processes can’t keep up. Automated V&V and full traceability lets you run your software on the new platform, see what breaks, fix it, test it, document it, and be ready in days, not months. You’ll be ready to ship the day the new OS goes out of beta, not 5 months afterwards.
- #56 pathfindersoftware.com/agile-in-an-fda-regulated-environment/