From reh@copland.franken.de Thu Jul 4 01:54 PDT 1996 Return-Path: Received: by silicon.csci.csusb.edu (5.0/SMI-SVR4) id AA08540; Thu, 4 Jul 1996 01:54:14 +0800 Received: (from uucp@localhost) by ns.sbs.de (8.6.12/8.6.11) id IAA08289 for ; Thu, 4 Jul 1996 08:35:07 GMT Received: from marina.scn.de(192.129.41.2) by ns via smap (v3.0.1) id sma008282; Thu, 4 Jul 96 10:34:37 +0200 Received: (from uucp@localhost) by marina.scn.de (8.6.11/8.6.11) id KAA27128 for ; Thu, 4 Jul 1996 10:38:40 +0200 Received: from unknown(162.1.103.22) by marina.scn.de via smap (V1.3) id sma027092; Thu Jul 4 10:37:56 1996 Message-Id: <199607040838.KAA27128@marina.scn.de> Date: Thu, 04 Jul 96 10:17:27 0200 Sender: reh@scn.de From: Bernd Reh Organization: Siemens Automotive Systems, Regensburg, Germany X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.05 9000/715) Mime-Version: 1.0 To: dick@csci.csusb.edu Subject: Your paper "can one size fit all ?" X-Url: http://www.csci.csusb.edu/dick/papers/rjb95b.one.size.html Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Length: 3087 Status: RO Hello! Here some thoughts on your paper: Basically I agree that there is not THE process. And even basically I'd like to remark that models like the CMM do not assume one process but have to be understand as a guidebook to build your own process. Working in the hard-constrained automotive industry however, I notice that these models still are away from being perfect :-) Let's go into details. You wrote on http://www.csci.csusb.edu/dick/papers/rjb95b.one.size.html: |> Lehman's S-type software is an implementation of a piece of mathematics and |> is judge to be correct vs this specification. These are mainly found in |> computer science departments and laboratories. For example a floating point |> package may be judge correct versus the IEEE standard for floating point |> and yet the standard is also likely to change and so force the software |> to evolve. |> Yes but this is too narrow. Protocols (like TCP/IP stack, CAN bus etc.) and algorithms are also S-type software. Unfortunately they are hidden in products which must appear fast (few suppliers/many customers). And if sloppyly implemented in the beginning they'll never debugged/redesigned. Instead the user has to live with unexplainable crashes and gets more new features for the next version. This means for these last programms development should even be split: Fast evolution for the top layer, thorough "S-type" process for underlying algos, protocolls and mathematics. |> I have no real data to prove this, however - that many practitioners want |> to reduce the time needed to develop software rather than change any other |> quality of the product - such as maintainability, readability, correctness, |> etc.. Here are some real data. In my company (Siemens Automotive, I'm in a SW Q Improvement Program) everybody (about 50 out of >300 programers I interviewed personally) WANTS to have better Q, maintainability, readability, correctness, etc. but nobody wants to DO anything fro it. Only measures which are obviously fit for reducing time for development are accepted easily (even if that time is lost again by longer debugging :-( ). |> Perhaps researchers and consultants in software engineering need to be |> trained in systems analysis, economics, and complex systems! Yes, definitely! |> In particular the powerful pressure towards low-cost rapid development |> is well known. ... |> The idea that the theory of complex adaptive systems can be applied to |> software markets is, as far as I know, original. Well, I do not think so but can't remember where I read it. I personally (young and idealistic as I am) found another factor leading to this situation: In mass SW business people make decisions instead of experts (cheap as posible in the short run). I always hoped that users would condem companies selling bad beta-versions for V1.0. Untrue as it seams. All in all: Agood approach you are taking. Carry on! -- Bernd Reh ------------------------------------------------------------------------------ I do not speak for Siemens -- but I hope Siemens will speak in favour of me !