Life Cycle Considerations for High Quality and Regulatory Compliant Software

By way of introduction I have developed, implemented, and validated computer/information systems for longer than I care to admit … they were still using punch cards to program room-sized computers when I entered the profession.  There have been a lot of changes since those early years in terms of technologies, processes, regulations, business operations, societal expectations, etc.

In reviewing recent computer validation related discussion boards, and evaluating conferences I have attended recently, there are a number of current topics of interest that are receiving attention.   These include Risk Assessment, Disaster Recovery, PLC Validation, Data Migration, Change and Configuration Management … all reflecting a continuing interest in experiences and approaches to system validation and verification.  Having just returned from a conference on software quality assurance I’d like to touch on a couple of key themes relating to the Software Development Life Cycle (SDLC).

The use of a defined System Development Life Cycle is well documented and established in most companies developing and implementing application software and systems supporting GxP regulated business processes.  Two aspects of SDLC continue to invite discussion.

USER REQUIREMENTS - The first of these is the need for well documented and verified User Requirements as a basis for all subsequent system development and verification activities.  Although specific estimates vary, there is general agreement that the earlier in the life cycle software defects are discovered the easier (and cheaper) they are to correct.  For best of class system development, up to 90% of defects could be caught at the Requirements phase if properly developed and reviewed.  Common issues with the development of User Requirements include:

• Lack of user input
• Incomplete descriptions
• Lack of clarity
• Limited detail
• Non-testable
• Continually changing scope.

It’s interesting to note that even though we recognize the criticality of well-developed and verified requirements we continue to struggle in developing requirements that are concise, unambiguous, complete, and testable.  We need to ensure that we set aside sufficient time during the life cycle to clearly identify and verify the requirements and intended use for the systems we develop and implement.  Additionally we need to invest in requirement gathering training for those individuals that are tasked with facilitating the development of this key element of the process.

AGILE SOFTWARE DEVELOPMENT - This brings us to a second ongoing debate regarding the overall methodology used to develop and implement systems.   From a regulatory perspective traditional waterfall methodologies in which we go through a formalized progression from User Requirements, to Functional and Design Specifications, to Coding and Configuration, to Testing and Verification, and finally to System Summary and Release has become well accepted.  Over the years alternative life cycle approaches have been introduced covering a broad range of industries and systems.

Agile concepts are currently receiving a great deal of attention, particularly with regard to their potential use in the Medical Device software arena, and by software providers offering Cloud-based solutions (a topic I’ll speak to in my next posting).  Without going into great detail or specific jargon, Agile methodologies generally focus on short, focused design and development cycles that deliver discrete units of functionality in a limited period of time (2-4 weeks).  This approach is supported with integrated teams having responsibility of all aspects of the software development process, including verification and quality.

Major concerns regarding the use of Agile in regulated areas focus on the level of documentation sufficient to produce evidence of adequate controls in software development and configuration.   With some adjustments in approach, some regulated companies are adopting Agile as a way to:

• Decrease development and implementation time
• Reduce defects through alternative requirements gathering techniques and iterative design
• While providing documented evidence of control at key points in the Agile life cycle

While we may not be ready to abandon more traditional life cycle approaches to system validation, we should keep an open mind with regard to alternative processes that result in improved software and system quality.  Some of these techniques may be particularly useful in addressing some of the upfront requirements issues mentioned earlier.   We should continually challenge our approach to developing and implementing reliable, high quality systems to support our regulatory needs … something I’ll continue to focus on in future postings.