Design Article
Better requirements analysis eliminates design defects
Mark Pitchford, LDRA Ltd.
11/27/2012 9:01 AM EST
Before finding a more specialized vocation, I spent more than 15 years in
industry developing and testing software. Back then the “waterfall”
process dominated software development with its distinct phases of
analysis, design, code and test. The theory was that each phase
would be performed in isolation with the output of one being the
input for the next. The intended output was a working system that
passed all tests.
With the waterfall approach, the purpose of the analysis phase was to refine the stakeholder’s vision of the system and produce a list of requirements, with those for software being itemized in the Software Requirements Specification (SRS). The SRS—always a revered document, its quality typically gauged by its thickness and weight—identified your status in the project team. You were somebody if you could proudly display it on your bookshelf! Of course, no sooner had a print run finished than the SRS was out of date due to a newly found error or ambiguity. No matter how much a project manager wished for the SRS to be error-free, it never was and the change log would begin increasing in size until a new print run became inevitable.
While the waterfall adherent’s wish for a stable requirements baseline was understandable, the process by its very design dooms a project to a constant state of instability. At its core is an ideal belief that each phase flows with near-perfection into the next and any errors or inconsistencies can be quickly smoothed out via a feedback loop. This may work for two phases; you effectively have a cut-down spiral process. But when you introduce a third or fourth phase, the feedback loops multiply to the point of being unmanageable. Thus when testing uncovers a problem with the SRS, that problem ripples up through all the phases with source code and design inevitably affected. Once the SRS is updated, changes ripple back down again no doubt spinning off secondary and tertiary problems along the way.
Second-class status
Contemporary software development processes and practices address many of the deficiencies found in the “waterfall” process. The Unified Process and Agile methods evangelize iterative approaches, which are well supported by modern configuration management, modelling, development and testing tools. Unfortunately, the greatest investment has been in improving the design and coding phases since engineers find software construction the most productive and exciting periods on a project. Requirements management and traceability—typically viewed as unattractive work—is often relegated to a secondary task, if done at all.
Although the commercial pressures of modern life have sharpened up processes in recent years, it remains the case that in general the automotive industry lags behind other sectors. It is no longer fair to suggest that testing is squeezed into the end of the project plan only if time allows, or that requirements documentation becomes little more than a historical curiosity once the pressures of milestones loom. However, in many cases there are too many echoes of the past problems, and few would argue that even the most recent development of automotive software has matched the rigorous ideals of aerospace with its strict DO-178C standard.
Unfortunately, for companies with project teams who operate like this, the cost of identifying and correcting software defects grows by orders of magnitude as they progress undetected from one process phase to the next. Catching defects as early as possible is critical to controlling cost and meeting project timescales.
Next: Faulty specs problems
With the waterfall approach, the purpose of the analysis phase was to refine the stakeholder’s vision of the system and produce a list of requirements, with those for software being itemized in the Software Requirements Specification (SRS). The SRS—always a revered document, its quality typically gauged by its thickness and weight—identified your status in the project team. You were somebody if you could proudly display it on your bookshelf! Of course, no sooner had a print run finished than the SRS was out of date due to a newly found error or ambiguity. No matter how much a project manager wished for the SRS to be error-free, it never was and the change log would begin increasing in size until a new print run became inevitable.
While the waterfall adherent’s wish for a stable requirements baseline was understandable, the process by its very design dooms a project to a constant state of instability. At its core is an ideal belief that each phase flows with near-perfection into the next and any errors or inconsistencies can be quickly smoothed out via a feedback loop. This may work for two phases; you effectively have a cut-down spiral process. But when you introduce a third or fourth phase, the feedback loops multiply to the point of being unmanageable. Thus when testing uncovers a problem with the SRS, that problem ripples up through all the phases with source code and design inevitably affected. Once the SRS is updated, changes ripple back down again no doubt spinning off secondary and tertiary problems along the way.
Figure 1: Despite attempts to refine
the waterfall process model such as this example from 1987, the
idealised notion that requirements can be set in stone usually
remained unchallenged1.
Second-class status
Contemporary software development processes and practices address many of the deficiencies found in the “waterfall” process. The Unified Process and Agile methods evangelize iterative approaches, which are well supported by modern configuration management, modelling, development and testing tools. Unfortunately, the greatest investment has been in improving the design and coding phases since engineers find software construction the most productive and exciting periods on a project. Requirements management and traceability—typically viewed as unattractive work—is often relegated to a secondary task, if done at all.
Although the commercial pressures of modern life have sharpened up processes in recent years, it remains the case that in general the automotive industry lags behind other sectors. It is no longer fair to suggest that testing is squeezed into the end of the project plan only if time allows, or that requirements documentation becomes little more than a historical curiosity once the pressures of milestones loom. However, in many cases there are too many echoes of the past problems, and few would argue that even the most recent development of automotive software has matched the rigorous ideals of aerospace with its strict DO-178C standard.
Unfortunately, for companies with project teams who operate like this, the cost of identifying and correcting software defects grows by orders of magnitude as they progress undetected from one process phase to the next. Catching defects as early as possible is critical to controlling cost and meeting project timescales.
Next: Faulty specs problems
|
|
|
|
|
Navigate to related information
WKetel
11/28/2012 3:37 PM EST
Of course it is true in any design or building effort that inadequate plans lead to inadequate results. So the majority of the effort needs to be spent in designing the specifications. After that, the project is just writing code. Of course, writing good and efficient code is no small task, it is a major challenge, no doubt. BUT the first part of the effort is in the development of an adequate specification. Defining responses to all possible exceptions at each stage of a program is both hard and tedious indeed. But if the task were trivial than everybody could do it well, and we can see that is not what happens.
Sign in to Reply