Software Development Management, Part 1, Overview
Medical Device Development, Software Architecture, Software Design, Software Design Transfer, Software Development, Software Development Plan, Software Development Process, Software Requirements and Specifications, Software Validation, Software Verification
One of the mysteries of my career in Medical Device development is that so many people find software development such a mystery. In my experience, while software itself can be complex, and carries a certain aura of mystery (I mean, it’s written in code for goodness’ sake), the software development process is really much like any other development process – you start with a plan and end with a verified and validated design whose implementation is transferred to manufacturing where it is replicated.
This is the first in a short series (mini-series if you will) about some things I’ve learned about software development that can really help the process turn out quality, deterministic software in an overall timely manner. This being the 1st tip in this mini-series, I’ll start with an overview of the software development process to help illustrate my perspective.
So here’s the tip:
Utilize a software development process that has the following essential ingredients:
- Software Development Plan
- Software Requirements and Specifications
- Software Architecture
- Software Design
- Software Verification
- Software Validation
- Software Design Transfer
Some will likely say sarcastically, “wow, that’s earth-shaking”, and I agree, there’s absolutely nothing novel in these ingredients, which is exactly my point. Sadly, in the many projects I’ve been involved with involving software, I’ve often found that either one or more ingredients is missing, or perhaps more often, the ingredients may exist but one or more is either woefully incomplete or not done in a manner that it makes any meaningful contribution to developing quality software.
Here is somewhat expanded discussion of the essential ingredients of a good software development process:
Software Development Plan (SDP)
The SDP is not really any different from any other Design and Development Plan – who’s going to do what when. FDA describes it like this: “plans that describe or reference the (software) design and development activities and define responsibility for implementation”.
Another item to include in the SDP is to identify others who will have input to the software development process. This could include input to any of the essential ingredients, the most important of which is Software Validation.
Since my definition of “validation” includes meeting User needs and expectations, the best software has input from actual or representative Users. And of course, the SDP needs to be reviewed, updated, and approved as software development evolves.
Software Requirements and Specifications
I would say that far and away the area with the most issues in software development is Software Requirements and Specifications. Most folks who do software development are familiar with a Software Requirements Specification (SRS), so the issue is often not whether one has an SRS, but the completeness and clarity of the software requirements themselves.
In previous Device Tips (Product Requirements and 3 C’s of Specifications) I discussed Requirements and Specifications in more detail, so everything I said about Rex and Specs in general applies directly to software. In summary, good requirements are written as complete sentences, include a verb, which is often used as a keyword, either specify the existence or non-existence of an attribute, or the acceptable range of a variable, are written so they can easily be reworded into a verification or validation statement, are written clearly (complete and unambiguous) so they can be completely understood without needing additional information, e.g., and anticipate the design and/or implementation.
One comment about Agile software development methods. While the core of these methods involve iterative and incremental development of software requirements software design and implementation, this doesn’t mean software requirements are not documented. At the end of the day (or let’s say the end of the software development), the software requirements still need to be clear, complete and documented, or they cannot be verified and validated.
Software Architecture
This is the top level design of the software that describes all the major software components and their relationships with each other. The overall software architecture provides a structure of functions that will meet all the software requirements. The best Software Engineers I have worked with all understand the critical importance of software architecture.
I even have a special class of Software Engineers I call Software Architects, and they are less than 10% of all the Software Engineers I have met. A Software Architect can grasp the complete set of requirements, and is able to visualize and define a structure of functions and their relationships that will work together to fulfill those requirements.
There are lots of different ways to document the software architecture but the bottom line is, it needs to be documented. It’s not a bad idea to go through the SRS and do a sanity check on whether the software architecture can support all the software requirements.
Software Design
This is the detailed structure of the software that describes how each software component operates, in a manner that will meet the software requirements for that component. Typical elements of a software design include inputs, processing and outputs for each component.There are lots of different ways to document the software design but the bottom line is, it needs to be documented.
One common misunderstanding is that the software source code is the software design. While this is technically possible, I would expect complete and clear descriptions of each software component in the source code Headers, and clear and complete comments for every data value, data element and processing step that is not easily understood by non-software engineers.
Oh, and a list of all the other software components that could call that component. You get the idea. In my experience, the only time I’ve seen this is when there were already separate software design documents in the way of structure charts, flow charts etc. More often the source code can only be understood by the one who wrote it, and even then…
Why not just create a few diagrams and perhaps a matrix or two to describe the software design? I know I’ve never been able to write good software without them.
Software Verification
This is a set of activities to “confirm that the design output meets the design input requirements”. In other words, verify that the software meets all the requirements and specifications in the SRS. Assuming one has a complete and clear set of the software requirements in the SRS, this is generally a set of tests that verify each software requirement.
Often the collection of all software requirements operating together can be quite complex. Thus a series of “test scenarios” and “test cases” can be constructed that not only cover all the software requirements, but attempt to mimic real world scenarios in actual use.
In support of requirements for Usability (another topic in itself), these scenarios should include “worst case” scenarios, and scenarios which verify all hazard and failure modes that are either detected or mitigated by the software.
Software Validation
This is a set of activities to “establish by objective evidence that device (software) specifications conform with user needs and intended use(s)”. In other words, confirm that that the software meets the needs and expectations of Users in actual or simulated use conditions.
Software validation should be performed under defined operating conditions on planned production target hardware to ensure that software will behave correctly in production units. Again, software validation should include testing under actual or simulated use conditions, so it can often be combined with software verification.
I prefer to call it “software verification and validation”. Lastly, as mentioned previously, the best software validation involved actual or representative Users in at least a portion of the validation activities.
Software Design Transfer
Design Transfer itself “ensures that the device design is correctly translated into production specifications.” For software this means providing the documentation and tools that allow the production staff to consistently incorporate the software into the product. At minimum this means providing a copy of the released software that goes into or is provided with the finished device, and a documented procedure for getting copies of the software into or onto the target medium.
This used to be programming EPROMS but currently typically involves programming FLASH memory, programming microcontrollers with built-in program memory, and even burning CD’s or DVD’s with elements of the software such as User Manuals.
Many companies also provide documented procedures for building the delivered software from the source code. This is an especially effective way to document the specific compilers, linkers, libraries, the overall build environment, and their locations, to ensure that all those elements essential for reproducing the delivered software, are available and controlled just as the source code needs to be. Many companies cover the reproducibility of the build within the Software Verification and Validation process.
Tip: give someone who’s not a software engineer the build procedure, and see if they can replicate your results.
If these ingredients are utilized and implemented in a complete and consistent way, you will be well on the way for developing great software.
P.S.: special thanks to Keith Breton of New Frontiers Software for his valuable contributions to this Device Tip. -BD