From: bwatt@csi.uottawa.ca (Bill Watt)
Subject: Debugging the process
Organization: Dept. of Computer Science, University of Ottawa
Date: Mon, 4 Jan 93 16:20:06 GMT

Thanks for the comments on, and corrections to, my initial posting 
on this subject.

"There is no short cut, because there is no end."  Korean anon.



1. Smaller firms
"There are approximately 10,000 firms in the [Canadian] software 
industry. ... Ninety percent have less than ten employees and only 
one percent have fifty or more employees." Software - Human 
Resource Issues and Opportunities, Canadian government report, 
March 1992. There must be as many small firms in other countries. 
The future for software engineering is bright. Let's not let 
capability assessment models for large organizations discourage 
the existence of smaller innovative software engineering firms. 
Already, Bell Canada has a capability assessment checklist 
[Trillium draft 2.2] based on the SEI model, but with additional 
requirements. Where is this leading? I did a plan for advancing a 
firm from Bell's definition of level 3 to level 4. The fixed cost 
overhead would discourage the existence of smaller firms. 
"Managing the Software Process" says a capable company must assess 
its subcontractors for conformance to the SEI model (Appendix A - 
A Software Process Maturity Framework "Subcontracting"). On page x 
of "Managing the Software Process" it says "In addition to working 
with very large projects, however, we have found that the same 
methods are effective for smaller groups." I'd like to believe 
this.


2. Precise definition
I may have a somewhat different perspective. My research in system 
science has been modelling "system development" with a knowledge 
engineering tool. A KE tool forces one to define and relate 
concepts precisely. Based on my KE model of system development, 
the software engineering "process" should be defined as a 
combination of the design and construction "processes" (rather 
than "production of quality software", "Managing the Software 
Process" pg 248). Requirements analysis should be a separate 
"process" from software engineering (a separate knowledge domain 
in my model).  The output from analysis would be the *input* to 
software engineering. With a more precise definition it should be 
easier to simplify a capability assessment model for smaller 
firms.

BTW, I managed the development of scientific software without 
having a lot of the problems I've heard about in the industry. Our 
"software process", if I may call it that, wasn't superior. I 
believe the difference was the *input* - formal math specs (often 
reviewed and published) from knowledgeable clients. I write this 
having studied of Dr. Humphrey's discussion on pg 25 that its a 
misconception that "we must begin with firm requirements".


3. Project/process management
Using a KE tool would force clarification of the distinction 
between process management and project management (chapters 6 and 
13 of "Managing the Software Process"). PM is an established 
management discipline with its own body of knowledge and proven 
procedures. One of those areas of knowledge, according to the 
Project Management Institute, is the management of quality.


4. The internal process
The software development process is partly external and partly 
internal (mental). Its up to the participants collectively to 
improve the external process. (Management is just a 
specialization.) Its up to the individual, with the support of the 
others, to improve the internal process. I've had good results 
helping invdividuals improve their internal process by handing 
back assignments to be done over again until they get it right. :-)


"Doan' you mind what Denis say", he whispered to me, "Denis, he 
quite a cutup. Sometime he run off at de mouf'."
 Last line of Jas. A. Michener's "Tales of the South Pacific"