|
This is the month for review of the IEEE's Software Engineering Book of
Knowledge. This is an attempt to define the body of knowledge of
our profession, in a way that can lay the groundwork for a licensed
profession. Usually I'd ignore something like this. There are hoards of IEEE
standards out there that are routinely ignored by anyone doing
commercial software development. Mostly they were written by academics
and those engaged in large government projects. Business people don't
consider government as a synonym for efficiency. But Cem Kaner, whose judgment I've learned to respect, does take
it seriously. In his blog
he says "If the SWEBOK is the basis for the licensing exam, the
practices in the SWEBOK will be treated as the basis for malpractice
lawsuits. People who do what is called good practice in SWEBOK will be
able to defend their practices in court if they are ever sued for
malpractice. People who adopt what might be much better practices, but
practices that conflict with the SWEBOK, will risk harsh criticism in
court. As the basis for a licensing exam, SWEBOK becomes as close to
an Official Statement of the approved practices of the field as a
licensed profession is going to get." So how flawed is the Swebok? This is a busy month for me, so I
haven't had time to dig into it in any detail. Just reading a few
sections is enough to raise a few red flags, and certainly to confirm
the view that Swebok puts undue emphasis on plan-driven development,
to a degree that rules out agile approaches. The first section I looked at was the one on design. Clearly
Swebok sees design as a separate activity from programming - a view
that's contrary to most of us in the agile movement. It hints at a
very detailed level of design being required as an input to coding and
testing - although it's impossible to say how detailed it actually
thinks it should be. The choice of books it came up with wasn't awful - although I was
alarmed that GangOfFour didn't make it to the recommended
list. The process section relied heavily on the notions of measurement
based control, which is seriously flawed since I've observed that
MeasuringProductivity is impossible. It's clearly strongly
based on Scientific Management principles, and as such utterly ignores
the role of people and human interaction issues in process. Again
since Individuals and Interactions trump Process, this is a huge hole
in the body of knowledge. The requirements section concentrates on producing a
comprehensive System Requirements Specification prior to commencing
development - again very much waterfall thinking. (Interestingly it
shows a spiral model picture - but only for producing the requirements
document!) There's no sense of exploring cost trade-offs in
requirements - in my view a vital element of any requirements
work. Well that's it for a quick scan. I may look more in the future.
But fundamentally I agree with Cem Kaner. Our industry is not
sufficiently mature to produce a body of knowledge of this kind yet.
We are still learning much about software development, and at the
moment there are a number of schools of thought. The software
engineering community has its own opinions, which may be appropriate
for a portion of software development. But there is no
widespread consensus yet.
|
