From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5ea968aeb8c7f10d X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Do I Really Need A Supervisor? Date: 1997/03/20 Message-ID: <5grdao$jo3@top.mitre.org>#1/1 X-Deja-AN: 226957740 References: <33301E64.110E@delphi.dasd.honeywe <3330BE71.695@earthlink.net> <5gqio9$hua@server1.erinet.com> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1997-03-20T00:00:00+00:00 List-Id: > People get this kind of managment ... of the SEI process in > organizations where the software engineering staff is to busy > to be bothered being part of the process groups who write the > standards and processes. This is truly the main problem with implementing the SEI model. We should document the process at it really is. Then slowly evolve some improvements. Too many organizations document processes as some process group wishes the processes to be. The activities in a process should only require steps that are the most economical way to produce the desired quality in the product. Those metrics which help you attain this economy are the ones that should be measured automatically, rather than measuring what is easy to measure. For example, at software maintenance time you are mainly interested in cohesion, coupling, and the number of bugs inserted by the maintainers, which are harder to measure than SLOC, and McCabe number of test paths. But SLOC and McCabe are easy to measure, so many measure them, and wonder why they continue to introduce bugs at the same rate.