Less strict separation of design and implementation phases for our domain

Question

I work for a company that has a very large government contract. As part of the realities of a government project, we are bound to process requirements that come down to us from the Department of Energy, and are responsible for meeting those requirements in our Software Quality Procedures.

The way we do most things around here is extremely cumbersome, going way further than the NQA-1 requirements actually call for. This means that in order to revise an administrative, non-safety piece of software in my project I am looking at a 6 month cycle in order to be able to get one line of code out to my users.

We are currently in the process of revising our procedures, which I was very excited about until I saw the draft of our "Design and Implementation" procedure. The author seems to shooting for a strict waterfall model in which Design and Implementation are completely separate activities.

The worst part is that in order to do any implementation you must have an approved design document (which is, like everything around here, easier said than done). If, once implementing, you want to change your design, you have to go back and modify your design document, get it re-approved, and go back to implementing.

This is, in my opinion, madness, and is actually worse than we have it today. The line between design and implementation can very easily get blurred depending on the project, and as long as you end up with a complete design document there is no requirement to do it sequentially.

We have a meeting so I (and a few other concerned co-workers) can plead our case for a less strict version of waterfall.

• Are there variants of waterfall design that allow for the parallel workflow that I'm envisioning with both the design document and implementation?

• Or how can I demonstrate that an iterative approach between both pieces is worth considering?

Answer 1

I'm not familiar with NQA-1, but I read the overview for federal project directors that the Department of Energy provides. I also found an IAEA slide deck about NQA-1. From what I can tell, NQA-1 is somewhat similar to other quality management standards that I am familiar with. It tells you that you must do certain things and that you must provide certain evidence of things being done, but doesn't dictate how you go about doing those things. It appears to be similar to a combination of AS9100 and DO-178 in the commercial aerospace world.

From both a business perspective, there are issues with going beyond the requirements for NQA-1 on all projects (especially those that don't fall into the scope of the NQA-1 requirements). The overview that I'm reading specifically identifies that NQA-1 and associated regulations apply to "activities affecting the safety related functions of those structures, systems, and components". The overview even goes on to say that those systems that do not perform safety-related functions "can fall under less stringent regulations and standards such as ISO-9000".

DO-178 calls for something called a "Design Assurance Level". Based on the impact that your software has to safety, the more requirements are levied upon it. This allows for software for an in-flight entertainment system to be developed differently than the software for the autopilot. NQA-1 may be binary (yes/no) rather than a tiered approach. My first recommendation would be to perform an assessment of the software under development. Both FDA guidance and aerospace industry guidance provide methods of determining the criticality of a system and the applicability of standards. I would suspect that similar guidance would exist as part of documentation associated with NQA-1. You would have to find that information and present that.

Once you present information about the applicability of NQA-1 to various projects and identify where it doesn't apply, you can make the business case about the impact (think in terms of dollars and hours) of following NQA-1 on projects where it doesn't apply.

From a process perspective (especially if you are compliant to ISO-9001 or similar), your documented process should account for projects that must adhere to NQA-1 and those that do not. Any external audits should be simplified by reviewing one set of process documents that apply to all projects. We (in the aerospace industry) accomplish this by defining a "minimal standard" that applies to all projects and additional requirements for each Design Assurance Level of DO-178.

At this point, you should have made the case for not applying NQA-1 to all projects and a less strict process for those projects. However, you'll still left with a sequential process. Since the process that you are aiming for is iterative, you can look at the work done in employing the agile methods in a regulated environment. Some papers have been written about R-Scrum, which is an application of Scrum in a regulated environment. Disciplined Agile Delivery is a newer process framework (based upon Lean Software Development, Scrum, Extreme Programming, and the Rational Unified Process) that accounts for what the author terms "governance". You should be able to readily find advantages of agile development, that coupled with the ability to use agile methods in a regulated environment should present a case for looking at the agile methods, not only in your non-critical projects, but to some extent in your critical projects as well.

If you are concerned with a transition to the agile methods being a huge leap for your organization, there is a "Waterfall with Overlapping Phases", or "Sashimi Model". Steve McConnell (via Peter DeGrace) describes this in Rapid Development. You still proceed sequentially through concept, requirements, architectural design, detailed design, coding/debugging, and system test. However, you start on the next activity before the previous one is fully signed-off on. For example, when you're doing your detailed design work, if there's a portion of the system that's well understood, you can begin to work on coding that portion. Ideally, the requirements and design for that portion of the system are stable and you detailed design has been peer reviewed to catch mistakes.

I would suggest looking at other industries - aerospace (AS9100 and DO-178) and medical (Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, General Principles of Software Validation; Final Guidance for Industry and FDA Staff). These are other highly regulated industries with large amounts of software and they have successfully implemented iterative development within their regulatory frameworks.

However, the only thing that you can do at this point is to build a case with some examples. Depending on your organization, you do need to be prepared to deal with an organization that isn't embracing the agile processes. Just because it's possible to selectively apply NQA-1 to projects or to develop a documented process that either is iterative or supports iterative development doesn't mean that your organization will choose to do so. You need to be prepared to simply live with the process that you have and work in a sequential process.

Without seeing the entire text of NQA-1, it's hard to write an extremely authoritative answer, but I hope this provides you with some avenues for discussion.