Re: Application Insecurity --- Who is at Fault?

[George Capehart <gwc () acm org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Crispin Cowan wrote:

<snip>

> > This is particularly interesting to me because I just had a doctoral
> > student come to me with an idea for dissertation research that
> > included an hypothesis that organizations at SEI 1 were better able to
> > estimate software development time and costs than organizations at SEI
> > 5.  He didn't seem to grasp the implications to quality, security,
> > life cycle maintenance, etc.
>
>
> Or it could be that the student is positing that the methods mandated in
> the SEI are a grand waste of time, which would be an interesting
> hypothesis to test. Certainly the successes of open source development
> models make a mockery of some of the previously thought hard rules of
> Brooks' "Mythical Man Month", and I dare say that traditional software
> engineering methods deserve questioning.

Sorry about the tardy comment.  The topic in the subject line comes up
over and over and each time the threads end up differently.  It reminds
me of the old Indian story of the blind men and the elephant.  I've been
working on trying to a general set of comments that I hope will provide
for a whole new round of discussion, but one in which we discuss the
elephant rather than ropes, tree trunks, fans, etc.  That's still a bit
of a way off.  In the meantime, I'd like to speak to this comment
because it's fairly specific and it's not directly addressing "security."

The CMM is a mechanism for describing how well disciplined an
organization's software development (or lifecycle) process is.  It does
*not* specify a particular methodology.  It only describes how well
disciplined and formalized the process is.  It aims to provide the same
kind of descriptive context for the software development process that
TQM, Six Sigma, etc. do for manufacturing.  The whole idea is to reduce
the variability in the process and make each step more repeatable.  By
definition, the more control one has over processes and the repeatable a
process becomes, the smaller the variance and standard deviation.  One
is much better able to estimate whatever parameter is of interest
(assuming it's meaningful and measurable).  The CMM provides a model and
some metrics that are useful in describing and measuring the software
development process.

Like every other tool, the CMM can be misused, and very frequently is .
. . in many different ways.  But used correctly, it is the perfect
mechanism for challenging and honing an organization's engineering
methods . . . whatever they are.  It doesn't specify a methodology, but
it *is* very good at showing an organization how well they are excuting
the methodology they have chosen to use.  If it's used to bring more and
more discipline into the process, the process becomes more predictable
and therefore, estimates will become more accurate and precise.  Problem
is, implementing the kind of discipline that the CMM measures is not
easy nor cheap, even though, in the long run, it pays off handsomely.
It typically implies major changes in the way processes are managed, and
that's typically painful.  It's also frequently unsuccessful in the
absence of strong change management process . . .

My 0.02$CURRENCY.

Cheers,

George Capehart

> Crispin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCZT0zmuGMnN1wNOoRAhrjAJ9GkZ2AYQ7K5Zn2xisKi3w29PxYwACgig/V
/QdXrnErrAtleBH6g5viWlE=
=rM1y
-----END PGP SIGNATURE-----