For anyone involved in risk management the thought of applying risk techniques to software opens many questions, including can we really identify risk areas in code?  Can we identify what software items contribute to hazardous situations? Can we identify mitigations and be sure we have covered all cases?

I was prompted to write this article after reading about the recent update of IEC 62304 Standard for Software Development for Medical Devices.  While we’ve been able to analyze hardware circuits and successfully identify risk and mitigations, software is not as straight forward.   Managing the development, integration and verification of software is a challenge in any case, think about identifying risks as this development takes place.  In software where so much is open to different interpretation, can we get to a point where we can agree on what is risky for each module/line of code? How do we address unproven execution paths?  What will be the impact of any future code enhancements?

Just as we’d do with hardware, a software risk identification process would start with bringing together the software design team to review the software architecture, identify the modules, both new and reused, and identify the risks for the planned design. Besides the technical risks – new software language, hosting systems, risks can also include complexity of software, development schedule, prototyping and verification schedule.   We’d also have to consider execution paths and the impact of future updates.   We could verify the identified risks and mitigations, but as we all know some code configurations would not have been verified.  What risks would these bring to the product?  What impact would software updates bring to the software implementation?

Success in identifying software risk/mitigations will require an understanding of the overall software process for the project including the software development plan, quality plan and verification plan.

Bio of Paul J. Kostek

Paul J. Kostek is a Principal of Air Direct Solutions, a systems engineering/project management consulting firm. He works with companies in defining system architecture, system requirements, interface definition, verification planning, risk management and software development standards. Paul received his BS from the University of Massachusetts, Dartmouth.   Paul works in a range of industries including: aerospace, defense, medical device and e-commerce.

Paul is a long-time volunteer with several professional engineering societies including IEEE, AIAA, SAE, INCOSE and PMI.  He also writes for the CERM.