wtwolfe@hubcap.clemson.edu (Bill Wolfe) (09/10/89)
The following letter appears in the September 1989 issue of the _Communications of the ACM_, and is presented for general discussion: INFORMATION SYSTEMS IS AN ENGINEERING DISCIPLINE The industrialized world is in the process of significantly enhancing its information system infrastructure. New information systems are being designed and built in such diverse areas as: air traffic control, funds transfer, military command and control, stock transactions, manufacturing, and engineering. During the next decade and beyond, the lives and safety of our citizens as well as the competitiveness of our country will depend on the correct functioning and efficiency of these new systems. It should be self evident that the specification, design, implementation, and validation of such systems is an engineering project of considerable difficulty. Information systems must meet exacting standards of performance and must be constructed within strict time and budget constraints. Many contain hundreds of thousands, even millions, of lines of code. Indeed the complexity of some of these systems rivals that of any artifact ever constructed by man. By any reasonable definition, information systems is an engineering discipline. The question I would like to raise is: who is going to be responsible for building these new systems that are so important to our national economy? To make the issue specific, suppose you were a manager responsible for developing one of these systems. Suppose your boss reminds you that the proposed system will operate in an environment in which human lives and property are at stake. He also reminds you of the many failures of such development projects -- systems that are late, grossly over budget, or never really work correctly. Your career as a manager is on the line. What professional would you select to be the manager of the system development project? A computer scientist? Not likely. By and large, the computer science community has ignored the entire area of information systems. Most computer scientists view people who implement information systems as rather low-tech COBOL programmers who were not smart enough to get a computer science degree. Many academic computer science departments actively brainwash their undergraduates that it is below their professional dignity to work in the information systems area. If you could find a computer scientist willing to undertake the job, you might find that he has the technical skills to design and implement the internals of the system -- the database, algorithms, communications, etc. -- but is weak in the engineering skills required to plan, organize, and manage the project. Most computer science departments simply do not consider it part of their job to instill in their graduates the engineering approach and engineering ethic that are part of the educational process in other engineering disciplines. The required software engineering course or senior project hardly makes up for four years of being immersed in a non-engineering culture. Indeed sometimes the computer science culture is actually anti-engineering. Instead of "If a bridge you design ever falls down, it is a personal blot on your professional career," we hear: "Everyone knows software has bugs in it when it is released." An electrical engineer? Quite likely, if the application is in military or engineering systems. You might find that the engineer has technical knowledge in the application area (for example, radar systems), the ability to design and build to specifications, and, if a senior engineer, the skills to plan, organize, and manage the project. However, you might also find that the engineer is weak in the computer science skills to design and implement the system internals. Thus, the project might be completed on time and budget, but might not employ up-to-date computer science technology (a situation that occurs all too often in military systems). An information systems professional? Quite likely, if the application is in business or management information systems. Unfortunately, you might well find that the information systems professional -- particularly one educated in one of the existing academic information systems programs -- is weak in both technical and engineering skills. As evidence for the last statement, I turn to the most recent report of the ACM Curriculum Committee on Information Systems, which proposes goals and a curriculum for academic information systems programs. Of the many possible quotes from that report, I include one that compares the information systems and computer science curricula: The IS curriculum differs from the computer science curriculum in the environment in which the program is taught, the employment environment for the graduate, and the depth of the technical environment required. 1. The IS curriculum teaches information systems concepts and processes within two contexts, organization knowledge and management knowledge and technical information systems knowledge, whereas computer science tends to be taught within an environment of mathematics, algorithms, and engineering technology. 2. The IS graduate is expected to work within the environment of an organization and to interact with both organizational functions and computer technology. The computer science graduate has less interaction with organization functions and more interaction with hardware and software technology. 3. In technical expertise, the IS curriculum places substantial emphasis on the ability to develop an information system structure for an organization and to design and implement applications. There is less emphasis on in depth skills in hardware and software design. The computer science graduate typically has less exposure to information requirement analysis and organization considerations but obtains greater expertise in algorithm development, programming, and system software and hardware. I interpret this quote as saying that the graduate of an information systems program may well have a good understanding of management and business applications, but is highly likely to be weak in both the technical and engineering skills referred to above. I can hear the criticism of the last remark: "Sure, you might need technical people down in the trenches doing the actual implementation, but the manager of the project does not need detailed technical and engineering skills." That view is succinctly expressed in a recent _Business Week_ article discussing failed information systems projects. Among the advice given is: Put senior, nontechnical management in charge of the project to help ensure that it is finished on time and within budget. Rubbish! Managing a large information system development project is a professional skill requiring significant technical and engineering background. The overwhelming body of experience shows that successful system development projects are managed by people who have both project management skills and technical knowledge in the application area. Projects fail, not because they are managed by technical people, but because they are managed by *incompetent* technical people who lack the necessary engineering skills and experience. Who then would you select to manage your information systems development project? In the broader context, which technical discipline will take the lead in designing and building the complex information systems our country needs to support its information infrastructure? Unfortunately, no academic discipline is providing the education and training needed to produce the people who will be the technical leaders in this important area: (1) Computer science departments do not view information systems as within their charter and produce graduates which lack the required engineering orientation and skills. (2) Electrical engineering departments produce graduates with an engineering orientation but without the required computer science skills. (3) Information systems departments do not view building information systems as an engineering task and produce graduates which lack both the required engineering and technical skills. One reason why academia is not producing information systems professionals with the required skills is that many of the businesses that employ their graduates also do not realize that building an information system is a highly technical, engineering endeavor. I include one additional quote from a recent article in _Datamation_ by a corporate personnel director describing the type of information system people he is seeking: We are going after the business graduate with a computer science minor, if we can get it. Business skills are more important than technical skills, which we can teach ourselves. We only require that candidates have one COBOL course. Then we put them through a six-week training course, and they receive additional training as their job requires it. This particular company is willing to entrust its information system development to people with no technical training whatsoever! One source of confusion is the name "information systems" itself. The academic and industrial information systems community commonly uses the term information systems in a rather narrow sense to refer only to management or business information systems. Yet the technology underlying information systems has applications in a large number of other fields; a military command and control systems is not unlike a factory management system, and an air traffic control system is the ultimate material tracking system. In the past, there have been significant differences in scale; business information systems were often relatively small (systems that could be built by a person who had taken only one COBOL course), while military and related systems were significantly larger, sometimes requiring millions of lines of code. That scale difference, however, is disappearing. Many modern business information systems are quite large and rival in complexity their military counterparts. If we want to attract bright engineering-oriented professionals to build these complex information systems, for business as well as military and related applications, we have to broaden our perspective as to what constitutes an information system. Information systems should be viewed as an engineering discipline that can be applied to a large number of application areas, including business information systems and military command and control systems, to name just two. It is much easier to state the problem than to propose a solution. Ideally an information system professional should have the technical knowledge of a computer scientist, the engineering skills of an electrical engineer, and the application knowledge of an information systems graduate (but for a wider range of applications than just business systems). An appropriate course of study might be taught within a computer science department, an electrical engineering department, or an information systems department, although the orientation and content of the curriculum would have to be quite different than that of most present departments. I believe that many of the most successful programs will be housed within a school or college of engineering. Information systems is an engineering discipline; engineers are the professionals in our society who build useful systems that are implemented on time and on budget; and engineering schools provide the educational environment in which future engineers are imbued over a four year period with the culture, the ethic, and the sense of professional responsibility that shape their entire professional lives and enable them to perform the engineering function. If we want our information systems to work correctly and reliably and be useful to real people, if we want them to be built within budgetary constraints, we have no choice but to place the responsibility for their development in the hands of people who have the necessary technical skills, but even more important, the engineering skills and orientation to get the job done -- and within our present university system, these kinds of people receive their education in schools of engineering. Although I believe that engineering schools are an appropriate place to house such programs, the issues go beyond any organizational entity within the university. My concerns can be summarized in two statements: (1) A large part of the information systems community, both academic and industrial, does not appear to understand the self evident fact that building a large information system is an engineering endeavor requiring significant technical and engineering skills. (2) No academic discipline views it as their job to educate technically trained, engineering oriented, information systems professionals. We say we are moving toward an information-based economy. Who is going to build our information systems infrastructure? Author: Philip M. Lewis Department of Computer Science State University of New York Stony Brook, NY 11794-4400 ARPA: pml@sbcs.sunysb.edu
diamond@csl.sony.co.jp (Norman Diamond) (09/13/89)
_Business Week_ writes: > Put senior, nontechnical management in charge of the project to > help ensure that it is finished on time and within budget. In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > Rubbish! Managing a large information system development project is > a professional skill requiring significant technical and engineering > background. Absolutely true. Business Week's advice results in products that don't work. It is important to produce the wrong answer as quickly AND as cheaply as possible, eh? This kind of practice is the reason why the U.S. (and especially Canada) now fall behind industrialized countries' economies. (In private industry, people get fired for expressing Mr. Wolfe's opinion, or mine.) -- -- Norman Diamond, Sony Corporation (diamond@ws.sony.junet) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
alpope@token.Sun.COM (Alan L Pope) (09/15/89)
> _Business Week_ writes: > > > Put senior, nontechnical management in charge of the project to > > help ensure that it is finished on time and within budget. > > In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: > > > Rubbish! Managing a large information system development project is > > a professional skill requiring significant technical and engineering > > background. > In article <10835@riks.csl.sony.co.jp>, diamond@csl.sony.co.jp (Norman Diamond) writes: > > Absolutely true. Business Week's advice results in products that don't > work. It is important to produce the wrong answer as quickly AND as > This topic was noticed only in time to see this last excerpting, so I may have missed some main point. Speaking of managerial hierarchies: There is no problem if the top-level management is non-technical. As long as no micro- management is done. I.e., the non-tech sticks to profits, markets, etc., and the tech mgmt stick to technical matters. Mutual respect -- if the Mgr (tech, or otherwise) is forced (or insists) upon having direct responsibility for realms not within their expertise, they are not good managers. Delegation of tasks to experts is appropriate management. I have managed projects under tech and non-tech people. The more they interfere the less likley the project will end successfully. I have worked for managers who did not know what a byte was (other than some computer term) but who had respect for my technical ability -- these projects cmae in under the proverbial "on time and within budget" category. I have worked for technical managers who were micro-managers, continously overriding any authority I was supposed to have. Staff were in constant turmoil -- projects didn't get done on time and went way over budget. I think Business Week is correct (based on just the quote above, not having read the article): if the company exists for "bottom line", as do most, get an expert in "bottom line" to manage. I presume that BW was referring to upper-level mgmt and not that for every four engineers you need one non-tech manager. I acknowledge that the Summary line is like "This is not a pipe". Alan L. Pope alpope@sun.com OR sun.com!token.Eng!alpope OR sun.com!Eng!alpope (depending on which mailer is running this week)
jimb@athertn.Atherton.COM (Jim Burke) (09/15/89)
In article <10835@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes: >_Business Week_ writes: >> Put senior, nontechnical management in charge of the project to >> help ensure that it is finished on time and within budget. >In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: >> Rubbish! Managing a large information system development project is >> a professional skill requiring significant technical and engineering >> background. >Absolutely true. Business Week's advice results in products that don't >work. I would like to state this even more emphatically. Business Week seems to cater to all the proffessional managers in the U.S. It places a premium on MBA type managers for all aspects of managing the corporate world. I have worked with projects headed by proffessional managers. They seldom succeed (if ever). Unfortunately, the only way to get into a position of being a competent manager is to get a technical degree, work a few years (long enough to become technically competent) and then go and get an MBA. It is unfortunate that, in the U.S., you must climb the corporate management ladder in order to have a voice. Precious few technically competent people do this. In other countries, namely Japan, the senior engineer has a voice and is highly respected. A manager of finance would never presume to tell him how he should build his product. Unfortunately, engineers do not have a voice in most U.S. companies when the decisions are made. You can have a Phd in engineering and 20 years of experience and some snivelling little Harvard MBA will set the parameters within which the project will proceed, often times encroaching very heavily into technical issues. I would assert that a highly experienced engineer understands his market far better than some recent MBA graduate. I know of one specific company that was totally ruined (ultimately was taken over for peanuts) because the president (who was fairly technical himself) placed most of the control in the hands of a young V.P. who was three years out of Harvard. (Sorry to pick on Harvard, but if they produce a fair number of bozo's , what are the rest of the pack doing?). Anyway, this guy proceeded to piss off the entire technical organization, the customer base, and anyone else he came into contact with because he fundamentally didn't understand that the engineering business is very different than banking, or retailing, or manufacturing, or anything else he had encountered in his vast three years. Anyway, what else would you expect Business Week to say??? -- ****** Views expressed herin are my own ******* Jim Burke - consultant 408) 734-9822 | I'll stop posting when they pry my jimb@Atherton.COM | cold, dead fingers from the smoking {decwrl,sun,hpda,pyramid}!athertn!jimb | keyboard.
mal@PacBell.COM (Martin A. Lodahl) (09/15/89)
In article <10835@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes: |_Business Week_ writes: | |> Put senior, nontechnical management in charge of the project to |> help ensure that it is finished on time and within budget. | |In article <6429@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes: | |> Rubbish! Managing a large information system development project is |> a professional skill requiring significant technical and engineering |> background. | |Absolutely true. Business Week's advice results in products that don't |work. It is important to produce the wrong answer as quickly AND as |cheaply as possible, eh? ... It amazes me to find myself agreeing with Bill Wolfe, but I also agree with this statement, and would like to extend it to cover any large, technically-intensive project. My principal assignment at the moment is to help salvage a collapsing data center move project that non-technical managers had nearly run into the ground ... -- = Martin Anders Lodahl Pac*Bell Minicomputer Ops Support Staff = = {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!mal 916/972-4821 = = If it's good for ancient Druids, runnin' nekkid through the wuids, = = Drinkin' strange fermented fluids, it's good enough for me!! 8-)} =
karl@ficc.uu.net (Karl Lehenbauer) (09/18/89)
> |> Put senior, nontechnical management in charge of the project to > |> help ensure that it is finished on time and within budget. > |> Rubbish! Managing a large information system development project is > |> a professional skill requiring significant technical and engineering > |> background. The question is, what is the job of management? While I think technical decisions should be made by people with an understanding of the technical aspects of the project, I think management can often be too involved with the technical issues. When a manager in charge of twelve programmers gets too technical, they become the thirteenth programmer in the group, rather than the manager. At that level, it is the manager's job (IMHO) to get his or her people to work, to get them to work mostly on what they're supposed to be working on, and to badger them to do some of the more unpleasant-to-programmers things like schedules and status reports. Inability or unwillingness to delegate responsibility is a common criticism of many new managers, usually levied at those fresh from a direct technical job. Once they "correctly" start delegating stuff, they lose direct contact with the technical end, and in a few years, their technical knowledge is out of date, unless they are very, very committed to maintaining it. Typically, the higher they are in the organization, the more technically out of date they are, because it has been that many more years since they were technical. Another question, how technical should they be? Our big project has well over a million lines & 400K statements of disk-resident software, plus firmware, diagnostics and a good deal of built-here hardware. It would take years for a committed programmer to achieve a comfortable knowledge of the innards of half the software. Clearly, management must deal with it at a significantly more abstract, hence less technical, level. (Pardon the disjointedness of this. I must hurry. ...more later if the discussion continues & warrants it.) -- -- uunet!ficc!karl "Have you debugged your wolf today?"
crm@romeo.cs.duke.edu (Charlie Martin) (09/19/89)
In article <6198@ficc.uu.net> karl@ficc.uu.net (Karl Lehenbauer) writes: >> |> Put senior, nontechnical management in charge of the project to >> |> help ensure that it is finished on time and within budget. > >> |> Rubbish! Managing a large information system development project is >> |> a professional skill requiring significant technical and engineering >> |> background. > >The question is, what is the job of management? While I think technical >decisions should be made by people with an understanding of the technical >aspects of the project, I think management can often be too involved >with the technical issues. Fred Brooks makes an interesting distinction on this question between the "producer" and "director" --- names chosen by analogy with movies. The producer role is what is spoken of in the first quotation: get it done on time and within budget. The director is in charge of getting a good product. They ought, by rights, to be considered equal, and to understand that they have equal roles in arriving at the desired result. Clearly, there are some points that have to be settled by negotiation between producer and director, like buying every programmer a second workstation (they have two hands, after all). But in general, the producer acts as the director's buffer against upper management, and the director keeps up with the technical details that the fiddling details of budgets don't leave the producer time for. I think Brooks talks about these roles reasonably clearly and in depth in Mythical Man Month. everyone should read it. Just don't pay attention to his suggestions about commenting PL/I programs. Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
UH2@PSUVM.BITNET (Lee Sailer) (09/20/89)
<6043@pbhyf.PacBell.COM> <6198@ficc.uu.net> <15624@duke.cs.duke.edu> The distinction between a 'producer' and 'director' is a good one. While I usually argue in favor of more technical expertise rather than less, in this case I'll do the opposite. In this train of argument being discussed here, people have been attacking the idea of putting a "manager" in charge. I think the original poster might have misinterpreted the original case being made. In the case study literature, there are many cases of well built, useful systems *failing* because the people they were built for weren't interested. There are even more examples of technical projects *failing* because senior management didn't care, or know to care, whether the project was successful. Because of these experiences, the current party line is that advanced information technology projects should not be funded UNLESS their is a committed person with funding and decision making powers who is willing and able to pursue the project to its finish (completion or cancelation). This, I think, is the 'Producer'. This person need not be technical. This person must understand the goals, strategy, and "bottom line" of the enterprise.
rcd@ico.ISC.COM (Dick Dunn) (09/20/89)
In article <6198@ficc.uu.net>, karl@ficc.uu.net (Karl Lehenbauer) writes: > > |> Put senior, nontechnical management in charge of the project... > > |>... Rubbish! Managing a large information system development project is > > |> a professional skill requiring significant technical and engineering > > |> background... >...When a manager in charge of twelve programmers gets too technical, they > become the thirteenth programmer in the group, rather than the manager... . . . > Inability or unwillingness to delegate responsibility is a common criticism > of many new managers, usually levied at those fresh from a direct technical > job... Karl's right--and there are practices which encourage this to happen. The worst is "promoting" people from engineering to management. In some com- panies, if you rise high enough you MUST become a manager--you run out of room for technical advancement after a while. The result is then that your best technical people get turned into managers whether they like it or not. It may be overt--"If you want to advance your career, it's time to take on some management responsibilities"--or relatively subtle. The saying some of us use for this is "It's always possible to turn a good engineer into a bad manager." Promote someone who likes engineering but not managing into a management position; the person will find a way to neglect the management and dabble in the engineering. (More enlightened companies have a nearly-complete "dual ladder" structure for advancement, where you can stay technical if you want.) >...Once they "correctly" start delegating stuff, they lose direct contact > with the technical end, and in a few years, their technical knowledge is out > of date, unless they are very, very committed to maintaining it... This is mostly OK; they'll retain some of the important understanding of what sorts of tasks are inherently easy or hard. You won't have to explain why finding a timing-related bug (critical-section failure, deadlock, etc.) with new hardware and new software might take anywhere from an hour to a week. That's (one example of) the sort of knowledge that a former technical person will retain through a lot of management. It's very hard to teach a completely non-technical manager (i.e., a never-technical manager) this sort of thing. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...I'm not cynical - just experienced.
simpson@trwarcadia.uucp (Scott Simpson) (09/21/89)
My boss just handed me this. Some excerpts from Golson, Dr. Hodges L., "How to Fail in Management", Georgia Tech Alumni Magazine, Spring, 1988. Dr. Golson is the president of Management Psychology Group in Atlanta. 1. Have all the answers. Don't admit that you don't know. Bluff your way through. 2. Manage tightly, inspect closely and delegate only what you have to. 3. Hire in your own image. 4. Don't worry about interpersonal skills. Managers are supposed to be tough-minded, hard-nosed, abrasive and even arrogant. 5. Always keep your next job in sight. Learn to play politics, avoid blame and sell upwardly. Be quick to rationalize and to project blame outwardly. 6. Don't worry about the long term. Keep focused on the immediate, here-and-now needs of the situation. Mortgage your future by making short-term, "earnings-per-share" decisions. 7. Focus only on the positive. Avoid bad news. If you do get bad news, shoot the messenger. Do anything you can to discourage subordinates from giving you bad news (i.e., by accusing them of being negative, not being on the team, etc.) 8. Pay an inordinate amount of attention to your image. Don't be caught without your three-piece dark suit, power tie, gold cufflinks, pocket hankies, pinky rings, Rolex, etc. 9. Have a problem with integrity. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)
rpb@dasys1.UUCP (Robert Brady) (09/21/89)
Although an understanding of the technical aspects of a job is neccesary for any decent manager, this is not all there is to it. The computer field is the first time in business history where the employees have had more skill than the management (ignoring easily learnable tasks). This throws some strange twists onto the management selection process as it would be an extraordinary man who learned the equivalent of 20 years in the field in both business and comp-sci. Although in the perfect world you would want to have each manager work through every position beneath him, this is not likely to happen in any near large company. -- +---------------------+------------------------------------------------------+ | Robert Brady | rpb@dasys1.UUCP | | Logic. | !cmcl2!{ccnysci,cucard,hombre}!dasys1!rpb | |"An elective despotism was not the government we fought for..." T.Jefferson |
markh@rtech.rtech.com (Mark Hanner) (09/22/89)
I definitely agree with the view that managers who micro-manage their product development cycle are doomed to failure. We follow the basic "producer"/ "director" model here where I (the product marketing manager) specify only the basic product requirements, and leave it to the project managers to design and build the product. There DOES need to be negotiation on the design spec, since I'm the one who spends the time to talk with customers follow market trends, and have insights into how the product should behave externally. To extend the analogy, the producer often has to go back to the director and say "you have to cut 20 minutes out of the final cut, or we'll only be able to show the picture twice a day, and won't make as much money." I don't think I should tell the director what to cut, just that something has to be cut (don't read too much into this as the analogy gets strained). Francis Coppola lucked out with "Apocalypse Now," but the fact that no producer has been able to rein him in has contributed to his failure to create another hit (IMHO). In defense of MBA's, sure there are a few "duds" floating around, but I've seen alot of startups fail because they had no non-techies and got so caught up in building "neat" or "theoretically correct" products that they forgot to make sure they knew where (and how much) their income was coming from. cheers, mark -- markh@rtech.COM "Crass generalizations may be justified by admitting 10 exceptions." -- marnie applegate
chrisp@regenmeister.uucp (Chris Prael) (09/23/89)
From article <10743@dasys1.UUCP>, by rpb@dasys1.UUCP (Robert Brady): > The > computer field is the first time in business history where the employees > have had more skill than the management (ignoring easily learnable tasks). I suggest that you earn a little bit about the histories of electrical, electronic, mechanical, civil, chemical, aeronautical, and automotive engineering. The biggest difference between those fields and computing is that no where near as many technicians managed to pretend that they were engineers in any of those fields as have done so in computing. Chris Prael
joannz@halley.UUCP (Joann Zimmerman) (09/26/89)
In article <34348@regenmeister.uucp>, chrisp@regenmeister.uucp (Chris Prael) writes: > I suggest that you earn a little bit about the histories of electrical, > electronic, mechanical, civil, chemical, aeronautical, and automotive > engineering. The biggest difference between those fields and computing > is that no where near as many technicians managed to pretend that they > were engineers in any of those fields as have done so in computing. One other very noticeable difference between other engineering fields and computing is in the amount of failure analysis to be found in the field. Did anybody reading this EVER take a course in failure analysis of software? In fact, where's the literature on this? There's all sorts of stuff on how bridges fail, and why buildings do/don't stand up, but there seems to be no real ability to analyze the stress on a software module, or the failure rate of software components. All I've ever seen is the anecdotal evidence (comp.risks and the like) and various platitudes about a quality development process producing quality software. How would we go about developing this into a real engineering discipline? -- "Come, my friends, 'tis not too late to seek a a newer world - " Joann Zimmerman Tandem Computers Austin, TX ...!{rutgers,harvard,gatech,uunet}!cs.texas.edu!halley!joannz
chrisp@regenmeister.uucp (Chris Prael) (09/27/89)
From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman): > One other very noticeable difference between other engineering fields and > computing is in the amount of failure analysis to be found in the field. A superb point. And one I have consistently overlooked. This is pure speculation, but it seems to me that there are two impediments to failure analysis in software. The first is my previous point of people functioning like technicians rather than like engineers, which means just hacking things until you have something that looks like it works (also known as prototyping). It is very hard to analize a design when there is none. The second impediment is the programmerly habit of patching things up as fast as they break. It would be interesting to analize the reported bugs from, say, a series of OS or translator releases. > How would we go about developing this into a real engineering discipline? Why not follow the leaders? Do what the real engineers do. Chris Prael
gary@dgcad.SV.DG.COM (Gary Bridgewater) (09/28/89)
In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman): >> One other very noticeable difference between other engineering fields and >> computing is in the amount of failure analysis to be found in the field. >> How would we go about developing this into a real engineering discipline? >Why not follow the leaders? Do what the real engineers do. Yes! Go buy a $1M software tester, hire a team of programmers to generate test patterns, another team to program the tester to run the patterns, another team to build a simulator to generate simulated output to compare to the tester output, another team to take your specs and generate code, another team to take your specs and emulate the machine to compare to the output from the simulator to see that is does the right thing (did we forget the team to write down what the right thing is?). But wait a minute wasn't this what 4GL was going to free us from? Engineers deal with systems that have a finite (possibly large) number of states so they can actually test or at least simulate all of them. If they can't then they cheat and make generalizations. Example: to test the load bearing limits on a bridge build a model and start with a lot of weight and keep adding big chunks of weight until it breaks then divide that by 2 (or 4, some fudge factor) and call that the limit. They don't have to get the exact limit just a safe one. So how do you apply that to software? Tell your boss "This foo works for all files less than 10Mb in size?" Your boss tells you "Make it work for all files - software isn't bridge-building." But look at a simple subroutine with, say, 4 32bit inputs. How many states? 2^128. How do you test them all or whittle that down automatically without a program that understands programs? It's got to be pretty smart and understand what can happen if you call a subroutine or if there are any possible side-effects. And for a reasonable project, you can have, what? hundreds of these subroutines? Thousands? If you have a program that understands programs then you should be able to synthesize the code from the spec and you can forget testing. You just need to verify the spec. Now we're back to 4GL. Where the heck is it? The only thing I think we can get from engineers is the same thing that the Structured Methodology people have been saying for years - design it right from the top down and then code to the design. Then get someone to check both these things. Have a test methodology and stick to it. Do regression testing on any changes. Document everything, always. Still, $1M chunks of otherwise useless hardware and hordes of expensive Computer Aided Software Developement types bowing and scrapping all over the place is an appealing thought. :-) -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.
chrisp@regenmeister.uucp (Chris Prael) (09/29/89)
From article <1142@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater): > In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >>From article <592@halley.UUCP>, by joannz@halley.UUCP (Joann Zimmerman): >>> One other very noticeable difference between other engineering fields and >>> computing is in the amount of failure analysis to be found in the field. >>> How would we go about developing this into a real engineering discipline? >>Why not follow the leaders? Do what the real engineers do. > Yes! Go buy a $1M software tester, hire a team of programmers to generate test > patterns, another team to program the tester to run the patterns, another > team to build a simulator to generate simulated output to compare to the > tester output, another team to take your specs and generate code, another > team to take your specs and emulate the machine to compare to the output from > the simulator to see that is does the right thing (did we forget the team to > write down what the right thing is?). In case you hadn't noticed, noone has ever figured out how to build a tester for the Golden Gate Bridge or the Sears Tower. Boy did/do you miss the point. The point is that real engineers DESIGN! And they document the design. Before they try to build what ever it is. Reletively few "programmers", "software engineers", etc. even know what the verb design means, let alone how to do it. I have been reading/hearing about magic pills, such as 4GL or CASE, that will be the perfect substitute for basic competence for 20 years. Oddly, not one of them has worked yet. > The only thing I think we can get from engineers is the same thing that the > Structured Methodology people have been saying for years - design it right > from the top down and then code to the design. Then get someone to check > both these things. Have a test methodology and stick to it. Do regression > testing on any changes. Document everything, always. Exactly! It works for them and it works when you do it in software too. There is no substitute for discipline and competence. Some of the new things may help a disciplined software engineer to do it better and/or faster, but they will never be a substitute for figuring out what you are going to do so that it is not significant who executes the design. Chris P
eugene@eos.UUCP (Eugene Miya) (09/30/89)
>DESIGN
Noble words, wish I could agree.
The problem is (best noted by Butler Lampson and Fred Brooks in various
articles and one book) is that software is an intrinsically different
thing that "hardware." The hardware people make mistakes (so you get cries
for certification). The software people try to mimic with design and
documentation. I don't think these will ever be enough.
I say this because I contrast the pre-computer parts of my
pre-engineering: things like mechanical drawing, etc. to the computer parts.
I can remember one teacher saying, "It's not adequate just to design
and something. You have to know and be able to construct it as well."
This of course lead to those drawings E shaped forms which have n roots
and n-1 spokes, something Escher would design: optical illusions.
In software on two flight projects, I've used 2 design languages and 1
requirements specification language (SDDL, PDL, and RSL/RSA). I think
the people who use and design some of this stuff are dreaming. Language
is kinda of a poor basis for modeling things. Real world hardware can utilize
geometric and mathematics. It follows conservation principles. Software
doesn't have any of this, and it still has to work. We will have a computer
literate public before we have design languages which "work."
The thing which disturbs me so much about software engineering education is
the emphasis on software project managerment. It's all taught late in a
programmer's life. If design languages and
specification languages were so good, we should be able to have little
kids using them: they use geometry at a very early age, and can be
good draftsman at a young age. I know the objections to this, but I think
it has to be that simple to use these tools. The need for software isn't
set by programmers and engineers for these types of projects. Engineers
design the best tools for themselves BECAUSE they have to use them. It's
also an iterative thing. Said managers and other politicians, etc.
who ask for big software projects have to learn to understand the consequences
of their requests, the side-effects, etc. Life's tough, computers aren't
going to resolve moral issues.
If engineers are going to get criticized for being engineers, this is part
of the reason why. No simple answers.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"You trust the `reply' command with all those different mailers out there?"
"If my mail does not reach you, please accept my apology."
{ncar,decwrl,hplabs,uunet}!ames!eugene
Live free or die.
ejp@abvax.icd.ab.com (Ed Prochak) (10/03/89)
In article <5296@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes: >DESIGN Noble words, wish I could agree. The problem is (best noted by Butler Lampson and Fred Brooks in various articles and one book) is that software is an intrinsically different thing that "hardware." The hardware people make mistakes (so you get cries for certification). The software people try to mimic with design and documentation. I don't think these will ever be enough. I say this because I contrast the pre-computer parts of my pre-engineering: things like mechanical drawing, etc. to the computer parts. I can remember one teacher saying, "It's not adequate just to design and something. You have to know and be able to construct it as well." This of course lead to those drawings E shaped forms which have n roots and n-1 spokes, something Escher would design: optical illusions. In software on two flight projects, I've used 2 design languages and 1 requirements specification language (SDDL, PDL, and RSL/RSA). I think the people who use and design some of this stuff are dreaming. Language is kinda of a poor basis for modeling things. Real world hardware can utilize geometric and mathematics. It follows conservation principles. Software doesn't have any of this, and it still has to work. We will have a computer literate public before we have design languages which "work." [text deleted] ... Said managers and other politicians, etc. who ask for big software projects have to learn to understand the consequences of their requests, the side-effects, etc. Life's tough, computers aren't going to resolve moral issues. If engineers are going to get criticized for being engineers, this is part of the reason why. No simple answers. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die. Eugene, I agree with you for the most part. I think you hinted at the key difference between software and hardware: model building, based on known mathematical fact. For example, aircraft designers can build a scale model and test its characteristics at a very low cost compared to the final product. They make use of Reynolds number and other aerodynamic parameters to be sure the model will behave like the real thing. We need a rule for scaling software so that we can test small, cheap models of the software system. I think this is what top-down design, structured design and object oriented design all are striving for. We need to be able to build the model based on the design, test it, if it doesn't work throw it away, if it does work then build the real thing. The problem has been that we don't build models. There has been proposals that we build prototypes instead. This may be okay as long as the prototype never leaves the development lab. Prototypes have to be treated as throw-aways, especially when they work! My personal opinion is that prototypes are not good enough, and that models of software systems are possible. What the techniques will be, I don't know. I agree that verbal descriptions cannot be good enough. Pictures are better (data flow diagrams and the like) but they aren't models, they can't be easily tested. There must be something we can use. Suggestions? Opinions? (BTW I am still looking for a reference to petri nets. If anyone can suggest a good introductory text, I would be very grateful.) Well, I made my point. Time to get out of here. bye ed prochak -- Edward J. Prochak (216)646-4663 I think. {cwjcc,pyramid,decvax,uunet}!abvax!ejp I think I am. Allen-Bradley Industrial Computer Div. Therefore, I AM! Highland Heights,OH 44143 I think? --- Moody Blues
varnau@cs.purdue.EDU (Steve Varnau) (10/04/89)
In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes: > >Eugene, > I agree with you for the most part. I think you hinted at the >key difference between software and hardware: model building, based on >known mathematical fact. For example, aircraft designers can build a >scale model and test its characteristics at a very low cost compared >to the final product. They make use of Reynolds number and other >aerodynamic parameters to be sure the model will behave like the >real thing. > We need a rule for scaling software so that we can test >small, cheap models of the software system. [deleted text] Here at Purdue University, I attended a talk about "Software Windtunnels" by Dr. D. Comer. In this talk he explored ways to test software (or software development methods) in ways similar to airplanes. He even used analogies to the Reynolds number. (Which is a dimensionless number.) All physics equations are homogeneous in their units, i.e. they are algebraically the same on both sides of the equal sign. (I can't recall the exact term he used for this concept.) Software engineering hasn't discovered this concept, or at least any equations using it yet. He seemed to think we should work on this and that scale factors could be found. On another topic (software safety), everyone is blaming errors on design, but many systems have been around so long that they no longer resemble the system designed. Has anyone considered preventative maintenance? People compare software reliability to bridge reliability. Even bridges fall down when they are not maintained (i.e. NYC is having this problem in a big way). -- Steve Varnau = varnau@medusa.cs.purdue.edu Purdue University, West Lafayette, IN (Software Engr. Research Center) IBM, Poughkeepsie, NY
varnau@cs.purdue.EDU (Steve Varnau) (10/04/89)
In article <8160@medusa.cs.purdue.edu> varnau@cs.purdue.edu (Steve Varnau) writes: > >Here at Purdue University, I attended a talk about "Software Windtunnels" >by Dr. D. Comer. Oooops, That was Dr. Richard DeMillo, not Dr. Comer. Sorry -- Steve Varnau = varnau@medusa.cs.purdue.edu Purdue University, West Lafayette, IN (Software Engr. Research Center) IBM, Poughkeepsie, NY
sharam@munnari.oz.au (Sharam Hekmatpour) (10/04/89)
In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes: > The problem has been that we don't build models. >There has been proposals that we build prototypes instead. >This may be okay as long as the prototype never leaves the >development lab. Prototypes have to be treated as throw-aways, >especially when they work! > My personal opinion is that prototypes are not good enough, >and that models of software systems are possible. What the techniques >will be, I don't know. I agree that verbal descriptions cannot be good >enough. Pictures are better (data flow diagrams and the like) but they >aren't models, they can't be easily tested. There must be something >we can use. Suggestions? Opinions? My opinion is that prototypes and models are both good, so long as we understand their limitations. Any abstraction or simplification -- and this is exactly what models and prototypes lead to -- involves loss of information. This is not necessarily bad, but the trick is to decide WHEN to abstract WHAT and HOW. I strongly belive that no tool or language can answer these questions. The only reliable source for answers has been, and still is, EXPERIENCE. In this respect, systems that have been developed for decades over and over again pose no problem, since there is such a vast body of knowledge and experience gathered around them. The real problem are NOVEL systems which, because of the success of this industry, are growing in number. Because we know little about the application domain of such systems, and because our experience from other systems does not usually scale up to such systems, development runs into complications. Now, compare this to other engineering disciplines. There, novel systems are few and far in between, so these difficulties are far less expressed. Hoping to find 'something' that can all of a sudden rescue us from this maze is like trying to answer unknown questions. Sure, there are notations, techniques, and ideas that are generally useful, but there is NO simple, universal solution. I for one think that our efforts are better spent thinking how we might train "Great Designers" (see F. Brookes) than to strive for "Great Notations". If only 1 in 10 people in this industry were as good as the best, we would have no problem to worry about. +----------------------------------------------+ | Sharam Hekmatpour <sharam@munnari.oz.au> | | Computer Science Dept., Melbourne University | | Parkville, Victoria, Australia 3052 | +----------------------------------------------+
eugene@eos.UUCP (Eugene Miya) (10/04/89)
In article <8161@medusa.cs.purdue.edu> varnau@cs.purdue.edu (Steve Varnau) writes: >> >>Here at Purdue University, I attended a talk about "Software Windtunnels" >>by Dr. D. Comer. > >Oooops, That was Dr. Richard DeMillo, not Dr. Comer. Distribution: comp.edu ^^^^^^^^^^^^^^^^^^^^^^ actually this isn't a followup field. DeMillo: Parnas's student who recently defended SDI at Stanford with Parnas on the opposite side. Actually, I have given some thought to this. I've written up a couple of pages of notes on the wind tunnel analogy. We have 24 (momentary 23) of the world's largest wind tunnels here. But I'm bad about writing real papers. Wind tunnels are kind of a neat laboratory for aerodynamics. The Wright Bros. invited the wind tunnel, and it probably gave them the edge in developing airplanes. Wind tunnels are now reaching their limits because their flows are fair too stable, far too linear. Cross flows, turns, dynamic things are difficult to simulate. I have thought lots about all kinds of other scientific apparatus: telescopes, refineries, reactors, "atom smashers," "tokomacs," lasers, etc. I've thought lots about other sciences and that other sciences don't regard "computer science" as a science, notably those which fund CS. My interest came as a result of a NASA internal effort to improve its use of computers. Efforts were directed by NASA HQ because we had the usual major computers problems: the software problem, the database, problem, and the performance problem. In time I became somewhat disillusioned. But about a year ago, I started thinking about aand have given 3 seminars on the topic of what I regard as "Empirical Compuert Science." This is a topic lacking books, having few articles, no methodology, etc. I've give the talk at OSU (Oregon), UCD, and UCSC. I'm giving it to a tough audience at Livermore in 4 weeks. Physicists: "real scientists" 8). Basically, my thesis notes that CS and SE are traditionally viewed as an offshoot of mathematics. True CS can use a lot more mathematical technique, but theory isn't enough. (Good Ref D. Knuth, AMM 1985) We sometimes spend too much time with math. It's the "Conservation Laws" which make physics so powerful. We don't have these, but I think we must learn two important things from other less than mathematical sciences: 1) we must learn how to be better observers, we must not leave this to chance as we do now, and 2) we must learn experiment design techniques, not from the statisticans, but from simple logic. I turn back to a good book on 2) from Campbell and Stanley. There are more elaborate books, but few simpler, and we have to start at a simpler level. We have a somewhat perverted idea of "Control" in computing which other sciences lack. It's both good and bad. The idea that a "Program" is an "experiment" is a wrong one. I think Feigenbaum said this originally. The seminar "ECS" covers these things. I've left out the section on the role of "Observation." I've no articles on this topic, but I'm trying to formulate something. I draw on some of the original ideas which got systems analysis started. I think computer scientists probably spend a little too much time with their own kind and need to mix with people in other disciplines. I do see other sciences coming in and learning CS principles, and I do get some moral support outside. Generally I am hopeful, some optimism, for the funding fo CS and SE, but I think we have something of an elitist/snobbish view. A tiny bit too academic (going back to Turing in fact). There are other consequences in education with the trend to computing and other sciences. I see the lack of interest in the more "experimental" sciences: chemistry: few chemistry sets, biology: yes we have to cut up a few frogs. We in CS are unfortunately a little too concern with minute details without seeing grander problems. So I have to spend time convincing physicists, chemists, geologists, that we need funding. (If you read Feynman's "Surely Your Joking," you will know he "sat at the tables" of other disciplines. We must do this, too.) If this sounds interesting, and I should publish, you are right, but part of my problem is the difficulty in bouncing ideas off on NASA people, we are kind of a jaded lot. NASA also has some strict ideas about the release of written information, and they have not discovered networks. They are worried about foreign governments, etc. Anyways, my problem not yours. Net flaming is easier. And I have to do my other work with priority. Hope you guys make it an engineering discipline. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die.
UH2@PSUVM.BITNET (Lee Sailer) (10/04/89)
> I agree that verbal descriptions cannot be good >enough. Pictures are better (data flow diagrams and the like) but they >aren't models, they can't be easily tested. There must be something >we can use. Suggestions? Opinions? I think DFD's are models, though you are right that the testing is problematic. The test is called a "walk thru." Some procedures (or perhaps better, guide- lines) have been developed that make some walk throughs more effective than others, and some people are better at it thena others. "Verbal descriptions" can be models too, especially if they are in languages like PDL, or structured English, or whatever. The final source code is a "verbal desription" is it not? That is, I can verbalize it over the phone to you, and you can write it down, and then you know more about the system than you used to. However, I didn't write this to quibble about whether these are models or not. I wanted to point out that models are reductions of the actual system, and by definition they omit some detail. It is usually necessary to build two or three different models of the system, using differnt modeling tools, in order to get a well rounded view of how the final system will behave. lee
bill@pd1.ccd.harris.com (Bill Davis) (10/04/89)
In article <EJP.89Oct3090900@abvax.icd.ab.com> ejp@abvax.icd.ab.com (Ed Prochak) writes: > The problem has been that we don't build models. >There has been proposals that we build prototypes instead. >This may be okay as long as the prototype never leaves the >development lab. Prototypes have to be treated as throw-aways, >especially when they work! I agree with throwing away prototypes when appropriate. But, what makes a prototype something that should be thrown away if it is working and providing useful functions? Is it because it has "lower quality" or because it has bugs? I use lots of software with bugs and the variation in "quality" is large. But, this "buggy" software still provides useful functions to me when I avoid the bugs. > My personal opinion is that prototypes are not good enough, >and that models of software systems are possible. What the techniques >will be, I don't know. I agree that verbal descriptions cannot be good >enough. Pictures are better (data flow diagrams and the like) but they >aren't models, they can't be easily tested. There must be something >we can use. Suggestions? Opinions? If a prototype is done in a language that uses constructs at a high enough level, then why is it not a design description? I do not have access to such a language, but it does seem reasonable that such a language could exist. The code executed might be high overhead and not suitable for many purposes that require lower overhead. But, wouldn't this still be a "model" in that it functions "to scale" (where scale involves slower instead of smaller). -- * Truth comes as an enemy only to those who have lost the ability to welcome * * it as a friend. ** Be thankful for your troubles. If your job did not have * * problems, they could hire someone else to do your job at half the cost. * Bill Davis EMAIL: w.davis@ccd.harris.com (<-best) uunet!hcx1!pd1!bill
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/05/89)
This discussion began with an article by Bill Wolfe highlighting a September CACM letter by Philip Lewis of SUNY. My only comment on the letter itself is that there is no reason to limit the application of engineering software to information systems -- all software systems should be truly engineered. The discussion has strayed into the typical dead-end concerns of who should manage software and how it should be managed, instead of properly focusing on how it should be engineered. Ed Prochak has brought the discussion back to the real issue. Ed writes in article <EJP.89Oct3090900@abvax.icd.ab.com>: > We need a rule for scaling software so that we can test > small, cheap models of the software system. I think this is what > top-down design, structured design and object oriented design all are > striving for. We need to be able to build the model based on the > design, test it, if it doesn't work throw it away, if it does work then > build the real thing. > The problem has been that we don't build models. > There has been proposals that we build prototypes instead. > This may be okay as long as the prototype never leaves the > development lab. Prototypes have to be treated as throw-aways, > especially when they work! > My personal opinion is that prototypes are not good enough, > and that models of software systems are possible. What the techniques > will be, I don't know. I agree that verbal descriptions cannot be good > enough. Pictures are better (data flow diagrams and the like) but they > aren't models, they can't be easily tested. There must be something > we can use. Suggestions? Opinions? Ed, we (Richard D'Ippolito, Kenneth Lee, Charles Plinta, Michael Rissman, Roger Van Scoy, and Jeffrey Stewart) have spent over three years here doing exactly what you suggest. Last spring I posted an article describing our efforts and successes with engineering modeling of software. I have updated the article to reflect more recent publications and conferences and have reposted it below. In article <1014@afit-ab.arpa> William A. Bralick writes: >It seems to me that architecture (as in buildings, not computer systems :-) >should provide a useful set of lessons for software engineers. The parallels >between software engineering and architecture (especially for a large, unique >building) are striking -- both are labor intensive, lengthy, expensive, >prone to schedule slippages and cost overruns, require not only a sound >design but also good management practices, both can benefit from standardized >parts, etc. Has any formal attempt been made to draw on (this pun >is intentionally left blank) architecture as a model for solving some >of the problems in software engineering? I am currently the project leader of a group here at the SEI called Software Architectures Engineering. Our primary focus for the last three years has been to apply traditional engineering practices and techniques to the development of software. Most notable among these techniques is the practice of modeling. I have found building design (architectural engineering) to be a particularly fruitful source of examples, parallels, and metaphors when describing the uses and value of software models. We have been able to show improvements in the software design process in several large-scale Ada projects by developing and applying engineering models. These models are just what you'd think they are -- architectural components representing solutions to the recurring patterns encountered in the various domains. As modeled solutions, they have known performance characteristics and structural style, and can be applied with other models of the same style to create the system architecture. In effect, one obtains reuse at the design level, as opposed to the component level. For example, in the flight-simulator domain, we developed a model (Object Connection and Update, or OCU) for connecting and updating the objects that comprise a system[1,2]. This model was used as the architectural base for the electrical and engine systems within the simulator. It has been successfully used on other flight simulator systems (C-17, MV-22, UH-1 and others), and is being considered as the model to be used in a tri-service agreement to train engineers, acquisition agents, and program managers in simulator development issues. In the C3I domain, we have produced a model for translating and validating incoming messages[3]. This model, the MTV (Message Translator and Validator), is being used on one large-scale project and is being considered for another. Preliminary reports by the customer indicate that by using the MTV model, they have achieved over a two-fold increase in productivity and an order of magnitude reduction in errors. Additionally, we are developing models for Ada real-time embedded systems and are presenting general papers on the uses of models for software development. One, in particular, that I have already presented discusses the models using examples from building architecture[4]. Another will be presented at the upcoming Tri-Ada conference here in Pittsburgh. So, to summarize an answer to Mr. Bralick's question, yes, we have made formal attempts to introduce the design practices of architects and other engineers to software development, and have already achieved successes. We invite you to come to the Tri-Ada conference to hear the following reports: Using Models in Software Engineering. Richard D'Ippolito, SEI. A Model Solution for the C3I Domain. Charles Plinta, Ken Lee, SEI. The Software Life-cycle With Ada: A Command & Control Application. Major Mike Goyden, USAF. Millimeter Wave Ada Shadow Program. Steven Pate, Hercules Defense Electronics, Inc. The first presentation is a general discussion of the models and techniques we used to create them. The second is a discussion in detail of the MTV model. The third, presented by the manager of the project that used the MTV model, gives the customer's experience with it. The fourth is a presentation by a customer who successfully used the OCU model, originally developed to solve the synchronizing and updating problems in flight simulators, to structure the executive in a missile seeker. If you can not make it to the conference, you can obtain these papers in the proceedings. Richard S. D'Ippolito rsd@sei.cmu.edu 412/268-6752 [1] An OOD Paradigm for Flight Simulators, 2nd ed. CMU/SEI-88-TR-30. [2] An Object-Oriented Solution Example: A Flight Simulator Electrical System Example. CMU/SEI-89-TR-5. [3] A Model Solution for C3I Message Translation and Validation. CMU/SEI-89-TR-12. Due November, 1989. [4] Software Development Using Models. International Workshop on Software Specification and Design, Pittsburgh, May, 1989. -- It is not the possible that determines what to hope for -- it is hope that determines what is possible. Richard J. Oman rsd@sei.cmu.edu -----------------------------------------------------------------------------
diamond@csl.sony.co.jp (Norman Diamond) (10/05/89)
In article <5328@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes: >But about a year ago, I started thinking about aand have given 3 seminars >on the topic of what I regard as "Empirical Compuert Science." So who says chaaos theory doesn't apply to our filed? :-) :-) -):) -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
jgn@nvuxr.UUCP (Joe Niederberger) (10/05/89)
In article <1142@svx.SV.DG.COM> gary@svx.SV.DG.COM () writes: >In article <34371@regenmeister.uucp> chrisp@regenmeister.uucp (Chris Prael) writes: >Engineers deal with systems that have a finite (possibly large) number of states >so they can actually test or at least simulate all of them. So how is this different from computerized systems ? Anyways, I always thought that "real engineers" used continuous models (i.e., differential equations) for many systems of concern. >But look at a simple subroutine with, say, 4 32bit inputs. How many states? >2^128. How do you test them all or whittle that down automatically without a >program that understands programs? Logic and mathematical reasoning have been shown to be equal to the task. Check, for example, "The Science of Programming" by David Gries. Of course, these techniques work best when run on an extremely exotic type of supercomputer known as the human mind. Fortunately, these are relatively ubiquitous these days. Joe Niederberger
munck@chance.uucp (Robert Munck) (10/06/89)
In article <89277.091206UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes: >I think DFD's are models, ... >"Verbal descriptions" can be models too, ... >I wanted to point out that models are reductions of the actual system, and >by definition they omit some detail. ... A good working definition of "model" is "X is a _model_ of Y if X can be used to answer certain questions about Y." This makes clear a number of things about the use of models, including the importance of defining the question set that a model is intended to answer and being careful to limit your questions to that set. It also says that the thing itself is a model of itself, with no sense of "reduction." -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
shf@well.UUCP (Stuart H. Ferguson) (10/13/89)
+-- bill@pd1.ccd.harris.com (Bill Davis) writes: | In article <> ejp@abvax.icd.ab.com (Ed Prochak) writes: | >Prototypes have to be treated as throw-aways, | >especially when they work! | | I agree with throwing away prototypes when appropriate. | But, what makes a prototype something that should be | thrown away if it is working and providing useful | functions? Is it because it has "lower quality" or | because it has bugs? No. Prototypes should be treated as a design lab. The original paper design invariably gets changed when being implemented, as concerns and collisions appear that were masked in the "pure thought" stage. As result, prototypes tend to be a Krazy Kwilt (tm) of patchs and partially abandoned approaches. Once the problem is fully understood, however, the experiment should be thrown away and the real system built. Why? Not because the prototype doesn't work, but because the design is bad. The first implementation of any program is, by definition, a prototype. The real problem is that many so-called products are really prototypes. | I use lots of software with | bugs and the variation in "quality" is large. | But, this "buggy" software still provides useful | functions to me when I avoid the bugs. Functionality is only a part of the picture. The rest of the picture includes reliability, support and enhancements. A good design makes this part of the process infinitely easier. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (ferguson@metaphor.com)