The Systems Engineering Approach
The systems engineering approach is also a linear process. Perhaps the best
example is the "Vee Model" as depicted in Figure 2
and described in detail by Forsberg, Mooz and Cotterham.[8]
Figure 2: The "Vee" Model (Mooz, et al, 1996)
But as Cantor explains:[9]
Quote
Systems engineering is concerned with designing, specifying, and verifying
the implementation of components of complex systems. It was developed to meet
the challenge of building large aerospace systems such as the Space shuttle and
NATO's command and control systems. These systems are often so large that their
development must be distributed to several companies. One firm, the prime contractor,
is assigned overall design and integration of the system. The prime contractor's
systems engineers gather and analyze the system requirements, then design the
system by decomposing it into a set of subsystems.
...
The subsystems may be developed by subcontractors, who are obligated by contract
to meet the requirements and specifications for the subsystems. The developed
subsystems are delivered to the prime contractor for integration into the total
system. The prime contractor's systems engineers verify that the subsystems meet
their requirements and oversee integration.
...
Initially, the systems engineering approach may seem to be a reasonable approach
to developing large software systems. Many systems engineering activities apply
to software development:
- Requirements gathering and analysis
- Architecture (identification and specification of the systems)
- Subsystem development
- Integration and verification
However, the systems engineering approach is based on assumptions that do not
apply very well to software development. Systems engineering assumes the requirements
are stable and the interfaces can be specified adequately before implementation.
In practice, the systems approach is a particularly rigid variant of the waterfall
approach and its lifecycle, and it inherits all the weaknesses of that approach:
- Classical systems engineering is document driven. Systems engineering efforts
are driven by formal documents that are developed by engineers and implemented
by developers. The problem is that the documents are never correct. The systems
engineers rely on their ability to make the document correct. They focus on creating
specifications that, once approved, are adequate for determining the design of
each subsystem. Any change to the document is managed by a cumbersome change control-board
system.
End Quote
Good features
- Most people who have an engineering background are very comfortable with the
systems approach
- It is very good wherever it is possible to describe, i.e. specify, the requirements
with a high degree of certainty
- The acquiring authority requires a thoroughly well-documented track record
or audit trail
- Consequently, it is popular with big government departments,
- Where money is not the limiting criteria, though competitive bidding might
be.
Not so good features
- The process is heavy on documentation
- It assumes that it is possible to arrive at near-perfect documentation that
is complete, and is truly representative of the ultimate "requirements"
- And can be frozen, and the authors, i.e. the stakeholders, can be held accountable
to those requirement specifications.
In summary, this approach does not fit well with the IS department's environment,
sometimes described as "the voyage of discovery", that we described
in our introduction.
8. Kevin
Forsberg, Mooz, M. and Cotterham, H. , Visualizing Project Management, 2nd Edition,
Wiley, 2000
9. Murray Cantor, Software Leadership: A Guide to Successful
Software Development, Addison-Wesley, NY, 2002, Appendix A.2, p162
|
The
"Waterfall" Process
