Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ads.com!saturn!jgautier From: jgautier@deimos.ads.com (Jorge Gautier) Newsgroups: comp.software-eng Subject: Re: CASE, the Little Red Hen, and Stone Soup Message-ID: Date: 28 Aug 90 20:50:57 GMT References: <28596@athertn.Atherton.COM> <28966@athertn.Atherton.COM> Sender: usenet@ads.com (USENET News) Distribution: comp Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415) 960-7300 Lines: 51 In-Reply-To: cimshop!davidm@uunet.UU.NET's message of 28 Aug 90 17:45:43 GMT In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > In article jgautier@deimos.ads.com > (Jorge Gautier) writes: > Bingo. The requirements are that it helps me create more software > better and faster. Any technology or methodology is acceptable as > long as it improves the quantity, quality and delivery schedule. > I am waiting for the "CASE" people to come up with a design. > Meanwhile, don't tell me that "tool integration" [sic] is the answer. > "Integrate" means to incorporate parts into a whole; show me the whole > first, and then I might buy the integration method. > > Aw, come on - you know better than this. Your first statement is not a valid > requirement - its just a vague expression of a desire. OK, how about lowering the cost of software development? Is that objective enough? My vague expressions are desiderata that could lower that cost. Time is money. Faster development and more software per unit time and less time fixing defects lowers the cost. Surely time and money can be measured. > CASE means Computer > Aided Software Engineering which presumes that there already is something > called software engineering. There are many, many "whole" methods for doing > software engineering (functional decomposition, object orientation, event > simulation, behavioral, etc.) - choose your favorite. Agreed. Let's keep the SE in CASE. Merry CASEmas. > CASE tools merely > implement pieces of these methodologies in a manner that someone has said > helps their understanding of the problem (one user might prefer a graphical > tool, another might prefer something more spreadsheet oriented). Tool > integration is not meant to build a new method of doing software development, > only allow those tools that implement parts of the method to work together. > Done in a standard way, the tools need not come from the same vendor. But I still haven't seen a whole computer assisted method that could significantly lower the cost of software development. The existing tools I've seen are so limited in scope and so disparate in design that I doubt much value could be gained from their integration. Obviously the intention of tool integration standards must be to persuade CASE tool developers to design new tools or redesign existing ones so that they "work together". If this produces an effective cost-lowering CASE environment, great. My point is that tool integration as I have seen it (databases, messages, etc.) is not sufficient to produce such an environment; a deliberate design will be required, and that's what I haven't seen to this day. -- Jorge A. Gautier| "The enemy is at the gate. And the enemy is the human mind jgautier@ads.com| itself--or lack of it--on this planet." -General Boy I speak for myself and for no one else.