-----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-----
