mcgregor@hemlock.Atherton.COM (Scott McGregor) (08/11/90)
CASE, the Little Red Hen, and Stone Soup (An CASE industry analysis in fairy tale terms) Copyright 1990 by Scott L. McGregor I am concerned about where our industry is going, or rather where it isn't. I am afraid that we are creating lots of capabilities and possibilities and few realities and actualities. I am afraid that there will be a backlash against what we have done by people who seek for solutions, hear that CASE has the answer, look past the possibilities in search of the solutions and disappointed turn away, only to criticize the industry as having inflated claims. I believe that many people want applications that will improve their ability to develop software--with little effort in understanding their current situation, or where they want to go. Of course, not everyone is this way. Some people DO know their current situation and where they want to go, and they chose CASE tools to help them get there. These are the early adopters of our industry. But most people don't have the time, the technical background or the inclination to find out the answers to these questions--they want the answers to be provided to them. In some ways, this is like the AI/Expert Systems situation a few years ago. Expert Systems provided a capability for creating great advisory systems. People were excited. Everyone wanted these powerful, accurate and (hopefully inexpensive) advise systems. But no one wanted to build them. Like in the story of the Little Red Hen, everyone wanted to eat the bread, but no one wanted to bake it. It is a lot of trouble to build and expert system, and you have to be one to build one. But if you are one, you need one less than someone else who is not. Of course a generic advice system could be used by anyone, a specialized one by only a few. How many are those few? Are there enough to pay for the effort of building such a system? Will they pay enough? Will you be able to find them? Will they be able to find you? It is so problematic that people pushed the general purpose engines and few specialized systems that really solved problems for people were sold. Several years ago, when PCs were brand new, a fellow I used to know brought home a PC from work and went to show it off to his wife. They sat down, booted the machine from a floppy, and then he proceeded to show her how you could start the basic compiler, write a program, and have it read something such as a name and then have it print out something. She typed in her name. He had it print out "Hello, Fiona!" She was non-plussed. "Have it tell me something new!" she said. He had type in another name and it printed that out. "No," she said "have it say something NEW. Something you didn't tell it." He explained to here how with programming you have to know what you want up front and then the computer does it for you. He showed her how it could multiply large numbers." She was still non-plussed. "What good is it if you have to know everything already when you start?" she stated as she left the room. I am afraid that this is the situation for all too many software development managers out there. They have too much to worry about to have time to spend on figuring out what they want. "Do you want to use the Yourdon methodology? Jackson? James Martin...?" someone asks. "I don't give a hoot about any of them--which one will make us instantly productive." Meanwhile we develop more systems in the vein of X-windows: policy free systems. And we suffer from the same problems of Xinitis--configuration is complex because so many decisions are left to the user. But look at how all the clamour is over added policy, in the form of Motif and Open Look and style guides. Companies regard it as an unfortunate burden that they have to have some expert define and build the company standard configuration file that everyone else will get. For many people CASE is stone soup. In the story of Stone Soup, some soldiers wander through a small village and ask everyone for some food. But everyone is suspicious of strangers, especially soldiers who once they find out what good food they are keeping might steal it by force of arms. So everyone says they have no food to give them. Finally, the soldiers give up and build a great fire in the central square. They borrow an old cauldron and fill it with water and put it on the fire. Then one of the pulls out some "magic stones" out of his knapsack and puts them in the pot. The villagers crowd around to see what the soldiers are doing and the soldiers say "we are making stone soup." "I've never heard of stone soup" says a villager, "is it any good?" "Well," says one of the soldiers, "we'd be glad to let you taste, but we have so little. But if you could contribute something to the pot, a carrot, an onion, a potatoe, a soup bone or a bit of beef, we'd be glad to share with us, besides, the contribution might improve the taste." The villager agrees and runs home and quickly returns with some carrots. Other villagers become curious as well and each runs home and returns with something to contribute. Soon the pot is full of vegetables and beef and chicken. The soup is served to everyone and everyone agrees the soup is the best they have ever had thanks to the flavor of the magic stones. For many CASE products it is much the same, I think. The real value is not in the product, but in the ingredients provided by the customer themselves in their customization, self-examinations and preparation for use of the new system. The CASE product is merely the catalyst. This isn't to put down the hard work of the developers of CASE products--I am managing development of one myself. But I am concerned by the knowing glances I get whenever I demonstrate one of these magic stones. There are some big challenges ahead for our industry. We need to develop a large CASE market with a taste for stone soup, or we are going to have to learn to make some hard choices and see how individuals respond to pre-prepared onion soup, chicken noodle, chunky beef and creamy mushroom soup. Soups where you just add water, not water where you just add your favorite soup ingredients. The challenge is particularly stong for those of us working on Integrated Project Support Environments (IPSEs) We may have to build systems with some of the decisions already made at the factory--and we may succeed or fail based upon the correctness of our predictions. So here's to better soup and may we not starve while waiting for someone else to bake the bread. --Scott McGregor
jgautier@deimos.ads.com (Jorge Gautier) (08/16/90)
In article <28596@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: > I am concerned about where our industry is going, or rather where it isn't. > I am afraid that we are creating lots of capabilities and possibilities and > few realities and actualities. I am afraid that there will be a backlash > against what we have done by people who seek for solutions, hear that > CASE has the answer, look past the possibilities in search of the solutions > and disappointed turn away, only to criticize the industry as having > inflated claims. Anyone who thinks "CASE" is one tool or methodology is being hopelessly naive. The backlash should be against the specific companies that are selling useless products. > I am afraid that this is the situation for all too many software development > managers out there. They have too much to worry about to have time to > spend on figuring out what they want. Those people then deserve what they get and will get what they deserve. > For many CASE products it is much the same, I think. The real value > is not in the product, but in the ingredients provided by the customer > themselves in their customization, self-examinations and preparation > for use of the new system. The CASE product is merely the catalyst. If that's how customers want to spend their money, let them. But if I were a supplier of that kind of product, I would be wondering about what I'll be selling to them after they wise up. -- 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
dlw@Atherton.COM (David Williams) (08/18/90)
In article <JGAUTIER.90Aug15151317@deimos.ads.com>, jgautier@deimos.ads.com (Jorge Gautier) writes: >>In article <28596@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott >>McGregor) writes: >> I am concerned about where our industry is going, or rather where it isn't. >> I am afraid that we are creating lots of capabilities and possibilities and >> few realities and actualities. I am afraid that there will be a backlash >> against what we have done by people who seek for solutions, hear that >> CASE has the answer, look past the possibilities in search of the solutions >> and disappointed turn away, only to criticize the industry as having >> inflated claims. >Anyone who thinks "CASE" is one tool or methodology is being >hopelessly naive. The backlash should be against the specific >companies that are selling useless products. It is not a matter of thinking that CASE is one tool or methodology; it is that when people try and take specific CASE tools and have them work TOGETHER that everything falls apart. In most circumstances you want all the tools you have to be able to share data and you hope this happens via a repository such as the one our company provides as an IPSE. But, most CASE tools are by *design* HOSTILE to data sharing or having their data stored in an OODB rather than in a native file system proprietary file/DB format. When surveys are conducted about what people want out of CASE tools an ultimate goal is for the tools to share (or hey REUSE) their information as the engineer(s) move thru the lifecycle. They become frustrated when they find that unless they have an IPSE that works real hard to provide this magic they don't get this. And so, all CASE tools get tarred with the same brush...right or wrong. What we engineers in the CASE industry need to do is champion the idea of Open Software Subsystems. We need to do what Jef Poskanzer did for graphic file formats (with PBM) and generate a PCF (Portable CASE Format) that is PUBLIC DOMAIN and provided as an option by all vendors and independent developers to facilitate data sharing among CASE tools. Vendors would still be able to have their own proprietary files/formats if they desired...after all it really should be the case that it is their algorithms that provide the functionality (tho in some circumstances elegant data structure + algorithms is what does the magic). In any case if data could be translated into the PCF then another tool could be PCF aware implictly and work with the data or vendors could provide translators that convert to their own format from PCF. Its not enough to have open operating systems (like unix vendors claim to be) we need to have open APPLICATIONS software. I know there are managers and engineers from various CASE/Software Engineering tool companies out there--why don't we get busy on this? We don't need an IEEE standards committee, we just need to talk and DO IT! >> I am afraid that this is the situation for all too many software development >> managers out there. They have too much to worry about to have time to >> spend on figuring out what they want. >Those people then deserve what they get and will get what they deserve. No its not that simple. These people are in trouble, they are a dichotomy to the CASE marketplace--on one hand they would really benefit from the technology and its benefits if all the tools could flow their data thru the lifecyle; we'd really give them some breathing space to do the right thing; on the other hand these folks are fighting to keep their systems and development projects from rigor mortis set in, and if they invest in CASE only to find that it does not give them the advantages they need after taking the hit on ramp up and methodology change you find yourself faced with one very unhappy customer. If CASE tools/environments would actually cooperate these folks would probably be beating down CASE vendor doors to get them. They aren't pain freaks, they are just smart enough to be wary of new things that promise the moon, and significantly impact their ALREADY hellish development schedules/environments. It is their JOB if they invest the companies resources, (money, people, time) and it fails. Being an MIS manager is not a cake walk, I've watched many of them get blown away in the course of trying to do the right thing. >> For many CASE products it is much the same, I think. The real value >> is not in the product, but in the ingredients provided by the customer >> themselves in their customization, self-examinations and preparation >> for use of the new system. The CASE product is merely the catalyst. >If that's how customers want to spend their money, let them. But if I >were a supplier of that kind of product, I would be wondering about >what I'll be selling to them after they wise up. Hmmm, in some cases they just move to another pigeon, ummm customer, in others its like drugs. They've already got a company hooked and now they just say it will all get better in the next release--the management guys who committed all that money to buying their product are not about to risk getting in trouble from their firms management for buying the "bad tool", so they just try and ride it out. Other brave souls just toss the product out and get real cynical about ANY CASE products. >-- >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 ------------------------------------------------------------------------------- David Williams -- dlw@atherton.com -- (408) 734-9822 x291 Atherton Technology -- The Software BackPlane 1333 Bordeaux Drive Sunnyvale, CA 94089 "CASE Environments R US" AIX,SunOS,VMS,Ultrix *
jgautier@deimos.ads.com (Jorge Gautier) (08/21/90)
In article <28966@athertn.Atherton.COM> dlw@Atherton.COM (David Williams) writes: > It is not a matter of thinking that CASE is one tool or methodology; it > is that when people try and take specific CASE tools and have them work > TOGETHER that > everything falls apart. In most circumstances you want all the tools you > have to be able to share data and you hope this happens via a repository > such as the one our company provides as an IPSE. Do you really think that data sharing (and/or "control" sharing for that matter) is sufficient to make disparate tools work together? > But, most CASE tools > are by *design* HOSTILE to data sharing or having their data stored in > an OODB rather than in a native file system proprietary file/DB > format. They are hostile to working with tools of different design. Data sharing by itself won't solve the problem of different design and data semantics. > When surveys are conducted about what people want out of CASE tools an > ultimate goal is for the tools to share (or hey REUSE) their information > as the engineer(s) move thru the lifecycle. Well, what I really want is something that helps me create more software faster and better. But that aside :-), for tools to work together they have to be designed to do so. You might be able to patch them up with tape and glue, but it is usually awkward, error prone and unreliable. Why do some people think that it is easy to "integrate" tools that were designed with different requirements in mind? > If CASE tools/environments would actually cooperate these folks would > probably be beating down CASE vendor doors to get them. You seem to assume that cooperating tools implies a useful system. As a potential customer, I don't care if "tools cooperate" or not, because to me, the partitioning and interfaces are arbitrary. Just show me what it does for me. Does it do something useful for me, better than what I do today? If not, I won't buy it. -- 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
davidm@uunet.UU.NET (David S. Masterson) (08/23/90)
In article <JGAUTIER.90Aug21153208@deimos.ads.com> jgautier@deimos.ads.com (Jorge Gautier) writes: In article <28966@athertn.Atherton.COM> dlw@Atherton.COM (David Williams) writes: > It is not a matter of thinking that CASE is one tool or methodology; it > is that when people try and take specific CASE tools and have them work > TOGETHER that everything falls apart. In most circumstances you want all > the tools you have to be able to share data and you hope this happens > via a repository such as the one our company provides as an IPSE. Do you really think that data sharing (and/or "control" sharing for that matter) is sufficient to make disparate tools work together? In neither of these statements has the word "tool" been defined. Without that definition, you can't say one way or the other whether its "sufficient". I think the purposes of the various CASE tools are sufficiently separable that the only thing needed to be shared amongst them is the data dictionary (note: I didn't define data dictionary). > But, most CASE tools are by *design* HOSTILE to data sharing or having > their data stored in an OODB rather than in a native file system > proprietary file/DB format. They are hostile to working with tools of different design. Data sharing by itself won't solve the problem of different design and data semantics. No, they are hostile to working with tools of different *vendors*. With sufficient standards (like, I take it, IPSE) on how tools could supply information in a form that is useful to other tools and with sufficient vendor use of the standards, CASE tools can share a lot of information. Nothing says that *everything* can be shared, but the differences in data semantics is not *that* different. > When surveys are conducted about what people want out of CASE tools an > ultimate goal is for the tools to share (or hey REUSE) their information > as the engineer(s) move thru the lifecycle. Well, what I really want is something that helps me create more software faster and better. But that aside :-), for tools to work together they have to be designed to do so. You might be able to patch them up with tape and glue, but it is usually awkward, error prone and unreliable. Why do some people think that it is easy to "integrate" tools that were designed with different requirements in mind? The point is the requirements. Tools can be designed to work together by working with a central standard (in this case, the data dictionary). The problem is finding such a standard and getting vendors to accept it. Then they will "integrate" in quite useful manners. > If CASE tools/environments would actually cooperate these folks would > probably be beating down CASE vendor doors to get them. You seem to assume that cooperating tools implies a useful system. As a potential customer, I don't care if "tools cooperate" or not, because to me, the partitioning and interfaces are arbitrary. Just show me what it does for me. Does it do something useful for me, better than what I do today? If not, I won't buy it. It seems from your message that you already feel that CASE tools can provide you with something useful, but don't see the need for cooperating "tools". A good reason comes from the UNIX market itself and "open systems". By having tools that can cooperate with other tools by providing a standard mechanism for other tools to use, then buyers of CASE tools are not locked into the single vendor, they can mix and match as they see fit. This will drive prices down due to competition, so the user wins. -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
jgautier@deimos.ads.com (Jorge Gautier) (08/24/90)
In article <CIMSHOP!DAVIDM.90Aug22135815@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > The point is the requirements. Tools can be designed to work together by > working with a central standard (in this case, the data dictionary). The > problem is finding such a standard and getting vendors to accept it. Then > they will "integrate" in quite useful manners. I agree that tools can be designed to work together, and I believe that that design should drive the tool integration standard. However, I don't believe that the mere fact of the existence of that standard will magically create useful CASE environments. If the goal is to obtain the implementation of a useful CASE environment via tool integration, I believe the path should be design of useful design and impl. of design and impl. of CASE env. -drives-> cooperating tools -drives->integration standard | enables | V implementation of useful CASE env. I want to see the design of a useful CASE environment as the "raison d'etre" for a tool integration standard. I have not seen such a design (yet?), so I am not ready to buy tool integration just because it *could* lead to a useful CASE environment. I see the value that tool integration standards could have for a developing industry. But as a client, I am interested in the useful CASE environment, not in how it's implemented. As a computer scientist, I believe there may be other paths leading to it. -- 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
davidm@uunet.UU.NET (David S. Masterson) (08/27/90)
In article <JGAUTIER.90Aug23110527@deimos.ads.com> jgautier@deimos.ads.com (Jorge Gautier) writes: I want to see the design of a useful CASE environment as the "raison d'etre" for a tool integration standard. I have not seen such a design (yet?), so I am not ready to buy tool integration just because it *could* lead to a useful CASE environment. I see the value that tool integration standards could have for a developing industry. But as a client, I am interested in the useful CASE environment, not in how it's implemented. As a computer scientist, I believe there may be other paths leading to it. Okay, what is a "useful" CASE environment? (You knew that was coming, didn't you ;-) Before designing such an environment, the requirements for such an environment need to be established. Anyone got an OORA CASE tool handy? ;-) -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
jgautier@deimos.ads.com (Jorge Gautier) (08/28/90)
In article <CIMSHOP!DAVIDM.90Aug27000637@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > Okay, what is a "useful" CASE environment? (You knew that was coming, didn't > you ;-) Before designing such an environment, the requirements for such an > environment need to be established. Anyone got an OORA CASE tool handy? ;-) 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. -- 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
duncan@dduck.ctt.bellcore.com (Scott Duncan) (08/28/90)
In response to a query about the requirements for a CASE environment, it has been said that > The requirements are that it helps me create more software ^^ >better and faster. ^^^^^^ ^^^^^^ and that > Any technology or methodology is acceptable as >long as it improves the quantity, quality and delivery schedule. Unfortunately, the basic requirements are totally subjective (i.e., valid for individual work habits and effort but not necessarily valid for people who have to interact with ithers in developing a system. By whose standards is the development "better": according to a customer's view of the end-product or some internal measure related to the developers' ease? How fast does it have to do this: just somewhat faster than someone, alone, can do it now or faster for a couple hundred people? I'm not defending CASE tools by any means, but requirements based on just one person's needs and standards don't help an entire industry deal with the issue of CASE. Perhaps CASE's biggest problem (and that of most tech transfer) is that just "[a]ny technology or methodology is [not] acceptable" to people, especially the latter. The implied methodologies behind many CASE tools and environments are just what many complain about. That is the methodology or practice offered by the CASE tool(s) (e.g., balancing data-flow diagrams) are not what they currently use to do create software, so asking them to do it is adding work, at least to their individual piece of the effort. >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. I think this is a valid comment; however, what many industry customers of CASE seem to be asking for is the integration approach, i.e., flexibility in mixing and matching pieces rather than a monolithic whole. They seem to be saying that they'd prefer an approach that offers them choices, rather than locking them into, potentially, a single vendor for their CASE environment. The "whole" is likely to be from the perspective of a single vendor unless many major vendors team up to agree on an architecture. (I realize this is happen- ing, to some extent, in the mainframe marketplace but, at the moment, just for that market and only for more traditional business data processing applications where many large CASE vendors focus their attention.) Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))
duncan@dduck.ctt.bellcore.com (Scott Duncan) (08/28/90)
Sorry for the mix ups in that last posting. I had a screen display problem which, apparently, obscured what was actually in the posting. Here's a cor- rected version. In response to a query about the requirements for a CASE environment, it has been said that > The requirements are that it helps me create more software ^^ >better and faster. ^^^^^^ ^^^^^^ and that > Any technology or methodology is acceptable as >long as it improves the quantity, quality and delivery schedule. Unfortunately, the basic requirements are totally subjective, i.e., valid for individual work habits and effort but not necessarily valid for people who have to interact with others in developing a system. By whose standards is the development "better": according to a customer's view of the end-product or some internal measure related to the developers' ease? How fast does it have to do this: just somewhat faster than someone, alone, can do it now or faster for a couple hundred people? I'm not defending CASE tools by any means, but requirements based on just one person's needs and standards don't help an entire industry deal with the issue of CASE. Perhaps CASE's biggest problem (and that of most tech transfer) is that just "[a]ny technology or methodology is [not] acceptable" to people, especially the latter. The implied methodologies behind many CASE tools and environments are just what many complain about. That is, the methodology or practice offered by the CASE tool(s) (e.g., balancing data-flow diagrams) is not what many currently use to create software, so asking them to do it is adding work, at least to their individual piece of the effort. >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. I think this is a valid comment; however, what many industry customers of CASE seem to be asking for is the integration approach, i.e., flexibility in mixing and matching pieces rather than a monolithic whole. They seem to be saying that they'd prefer an approach that offers them choices, rather than locking them into, potentially, a single vendor for their CASE environment. The "whole" is likely to be from the perspective of a single vendor unless many major vendors team up to agree on an architecture. (I realize this is happen- ing, to some extent, in the mainframe marketplace but, at the moment, just for that market and only for more traditional business data processing applications where many large CASE vendors focus their attention.) Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))
davidm@uunet.UU.NET (David S. Masterson) (08/29/90)
In article <JGAUTIER.90Aug27121540@deimos.ads.com> jgautier@deimos.ads.com (Jorge Gautier) writes: In article <CIMSHOP!DAVIDM.90Aug27000637@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > Okay, what is a "useful" CASE environment? (You knew that was coming, > didn't you ;-) Before designing such an environment, the requirements > for such an environment need to be established. Anyone got an OORA CASE > tool handy? ;-) 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. 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. 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. -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
jgautier@deimos.ads.com (Jorge Gautier) (08/29/90)
In article <CIMSHOP!DAVIDM.90Aug28104543@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > In article <JGAUTIER.90Aug27121540@deimos.ads.com> 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.