%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Forum for Academic Software Engineering % % (The Electronic Version) % % % % Volume 2, Number 6, May 29, 1992 (FASE No. 7) % % % % _____________________________________________________________________ % % % % 1 Tenure Track Faculty Position in Undergraduate Software % % Engineering Education % % % % 2 Chi Satellite Program Announcement - Managing the Human-Computer % % Interface % % % % 3 Workshop on OO Technology and Software Engineering % % % % 4 Ethics Education % % % % 5 Software Engineering Education Netnews Debate % % % % 6 A New Text Book on Software Engineering % % % % 7 The 13th National Computer Conference & Exhibition % % _____________________________________________________________________ % % % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1====================================1====================================1 From: mjl@cs.rit.edu (Michael J Lutz) Subject: Tenure Track Faculty Position Tenure Track Faculty Position Undergraduate Software Engineering Education Department of Computer Science The Rochester Institute of Technology Applications are invited for a tenure track faculty position in the Department of Computer Science of the Rochester Institute of Technology beginning in September 1992. Candidates must have a strong, demonstrated commitment to software engineering education, especially at the undergraduate level. The department is embarking on a substantial curriculum reform with the goal of defining a lower-division course sequence that provides a foundation for upper-division tracks in both computer science and software engineering, while ensuring that students are adequately prepared for their mandated cooperative education experience in industry. The successful candidate is expected to actively participate in the development of the lower-division core, as well as the reevaluation and extension of the current upper-division concentration in software engineering. In addition, opportunities are available for teaching in the masters level Software Development and Management program, housed in the Department of Information Technology. While a Ph.D. is desireable, candidates with a masters degree and a visible record of achievement in software engineering education are encouraged to apply. In particular, the department is seeking an individual who is committed to undergraduate education, and who will complement and enhance the department's reputation for teaching excellence. Applications will be accepted until the position is filled. Please submit a current resume to Ms. Renee Fedeli Office of the Director School of Computer Science and Information Technology Rochester Institute of Technology One Lomb Memorial Drive Rochester, NY 14623-0887 Inquires may be made to the address above or by electronic mail to swefac@cs.rit.edu The Rochester Institute of Technology is an Affirmative Action/Equal Opportunity employer and encourages applications from women and members of minority groups. 2====================================2====================================2 From: lwerth@cs.utexas.edu (Laurie Werth) Subject: chi satellite program announcement Managing the Human-Computer Interface: Give your organization the competitive edge A Live Satellite TV Broadcast Presented by Ben Shneiderman With featured interview guests: James Martin: author of 80 books, lecturer, consultant, Pulitzer Prize nominee David Nagel: Senior Vice President, Advanced Technology Group, Apple Computers June 24, 1992 1-3pm Eastern Time University of Maryland Instructional Television Intended Audience This course is directed to high-level executives, middle-level managers and technical leaders who are responsible for human- computer interfaces. This includes policy makers who select commercially available interfaces for their organization, and those who develop new interfaces for internal use or for sale. Evaluators, trainers, marketers, office managers, and executives in technology intensive organizations will also benefit from this program. Prerequisites Knowledge of and management experience with user interfaces on personal computers, workstations, or mainframes. Benefits This Executive Overview will give you a state-of-the-art report on managing user interface development and deployment. You will learn about contemporary management methods that make dramatic differences in project outcomes. Description Successful managers recognize a grand opportunity to dramatically alter computer-oriented workplaces with contemporary Graphic User Interfaces, e.g. Macintosh, MS Windows 3.0, OSF/Motif, NeXT, etc. The business case is clear: improved interfaces can substantially increase productivity and quality, reduce stress, fatigue, and errors, and enable users to generate creative solutions to their problems. This program combines scientific management approaches to project planning and evaluation. We explore how management policies and design improvements can have powerful effects on user learning times, speed of performance on tasks, rate of errors, subjective satisfaction, and human retention over time. Usability laboratory testing, guidelines documents, and user interface management software tools are now seen as the three pillars of successful user interface projects. New designs offer intriguing breakthroughs in information visualization, image processing, search strategies, direct manipulation interactions, and user-controlled adaptation, but concerns about intellectual property (copyright & patents) and privacy protection raise new challenges for management. Software interfaces enable mangers to restructure workplaces through computer supported cooperation, electronic mail, bulletin boards, group decision support, electronic meeting systems, and shared databases. Hardware advances contribute through high- resolution displays, notebooks with styli, high-precision touchscreens, high-bandwidth networks, and parallel computation. Course Outline Topics - motivation for interest in human-computer interface - defining graphical user interfaces - scientific evaluation methods - three pillars: usability labs, guidelines documents, software tools - case studies of successes - setting strategic management goals - what to do today Discussion with phoned and faxed questions Enrollment This live satellite course will be broadcast from the University of Maryland Instructional Television System via Ku and C Bands. In order to view the broadcast, access to a satellite dish is necessary. Contact your organization's training or conference director to ask if he or she can organize a satellite downlink and obtain a site license. A site license will be $900, and it includes permission to videotape. For information on the broadcast, call (301) 405-4905 or FAX (301) 314-9639. The broadcast will be in cooperation with the National Technological University (NTU). If you cannot arrange for the live downlink, ITV will make a videotape and mail it to you for $1100. Presenter Ben Shneiderman is Head of the Human-Computer Interaction Laboratory, Professor of Computer Science, and Member of the Systems Research Center all at the University of Maryland, College Park. He is an international lecturer/consultant for many corporations (AT&T, IBM, Apple, GE, NCR, etc.) and government agencies (NASA, Library of Congress, etc.). Dr. Shneiderman the author of the recently published second edition of Designing the User Interface: Strategies for Effective Human-Computer Interaction and the 1980 book Software Psychology: Human Factors in Computer and Information Systems. He was co-author of the world's first commercial hyperbook Hypertext Hands-On! Dr. Shneiderman is editor of the Ablex Publishers series on Human-Computer Interaction, author of more than 150 technical papers, creator of the Hyperties hypermedia authoring system, and organizer of the annual satellite TV program on User Interface Strategies. 3====================================3====================================3 From: Jeff Lasky Subject: Workshop on OO Technology and Software Engineering CALL FOR WORKSHOP PARTICIPATION OBJECT-ORIENTED TECHNOLOGY and SOFTWARE ENGINEERING August 11 - August 15, 1992 Rochester Institute of Technology Rochester, NY Sponsored by the National Science Foundation Undergraduate Faculty Enhancement Program The purpose of this workshop is to provide undergraduate teaching faculty with an intensive exposure to the relationships between object-oriented technology and software engineering. The workshop is offered to faculty who will typically have at least five years of undergraduate teaching experience. Funds will be provided to cover lodging and meal costs during attendance at the workshop. In addition, participants are eligible to receive a $250 stipend. (Employees of the federal government are not eligible for any financial support). It is expected that the faculty member's home institution will provide travel funds. The workshop ends on a Saturday so that participants can depart on Sunday and take advantage of discount airfares. There is no workshop fee. Interested faculty should e-mail the application form to jal@cs.rit.edu or to JALICS@RITVAX. Applications will be processed as received until available workshop places are filled. Workshop Overview (Preliminary) This workshop will address the application of object-oriented principles and concepts to the development of high quality software systems. The focus will be primarily on front-end life-cycle issues of analysis, specification, and design, though there will be some discussion of representative object-oriented programming languages such as C++, Smalltalk, and Eiffel. Topics include: Fundamental concepts of object-oriented technology: Objects as state, behavior, and identity. Classes of objects. The role of inheritance in design and implementation. Object relationships: is-a and has-a. Object-oriented technology and the development cycle: Object-oriented analysis (OOA) Object-oriented design (OOD) and its relationship to OOA. Object-oriented implementation. Comparison to traditional methods (e.g., SA/SD). Frameworks: cooperating groups of objects. User interface frameworks (MVC and MacApp). Operating system frameworks (Choices). Survey of OOA/OOD methods CRC (Class/Responsibility/Collaboration) Booch OOD notation. Object Modeling Technique (OMT) of Rumbaugh, et. al. Reusability and software evolution. Reusable design components. Reusable implementation components. Incremental enhancement of existing components. The role of formal methods. Entity-relationship models of static relationships. Formal specification of object operations. Object-chart specification of inter-object interactions. Overview of object-oriented programming languages. Smalltalk C++ Eiffel Outstanding issues. Testing of object-oriented software. Tools to support object-oriented development. Life cycle models for OO development. The role of OO technology in CS/SE education. APPLICATION Name Title Address Work telephone Home telephone Electronic mail address How many years experience do you have teaching undergraduates? In what area(s) do you usually teach? Please briefly state your motivation for attending the workshop: Please direct inquiries to the above e-mail addressees or to : Professor Jeffrey A. Lasky, Workshop Director Rochester Institute of Technology Department of Information Technology Rochester, NY 14623 (716)-475-5178 RIT admits and hires men and women, veterans and disabled individuals of any race, color, national, or ethnic origin, or marital status in compliance with all appropriate legislation, including the Age Discrimination Act. The compliance officer is James Papero. 4====================================4====================================4 From: Don Gotterbarn Subject: Ethics education I received the following announcement. It should be of interest to both industry and academe. Many industrial organizations are beginning to discuss ethical issues as part of their training programs and including ethics as part of an employee's performance review. I know the videos deal with many real world computer ethics issues. ----------------------- forwarded message -------------------------- TEACHING SOCIAL AND ETHICAL IMPLICATIONS OF COMPUTING: A "STARTER KIT" The Research Center on Computing and Society at Southern Connecticut State University and Educational Media Resources, Inc. (a not-for-profit organization specializing in educational programming) have assembled a "Starter Kit" for teachers who wish to introduce social and ethical implications of computing into their computer science or computer engineering classes. The "Kit" can also help computer science departments fulfill national accreditation requirements (CSAC/CSAB). The "Starter Kit" includes three video tapes and two monographs: VIDEO TAPES: No. 1--Teaching Computing and Human Values (45 min.) No. 2--What Is Computer Ethics (45 min.) No. 3--Examples and Cases in Computer Ethics (45 min.) Monographs: No. 1--Teaching Computer Ethcis (110 pages) No. 2--Computing and Social Responsibility: A Collection of Course Syllabi (142 pages) Subscribers to this LIST who want more details will find some information below and can get further information by contacting the Research Center on Computing and Society. * * * * * (additional details for those who want them) * * * * * Video Tape No. 1: (45 minutes) TEACHING COMPUTING AND HUMAN VALUES--This video program includes leading scholars in the field of computing and human values addressing three key questions: Why should computer science and computer engineering curricula include materials on social and ethical implications of computing? What is computer ethics? How can computer ethics be taught? The program includes: Susan Conry-- Chair, Computer Science Accreditation Commission, Clarkson University Gerald Engel-- ACM/IEEE-CS Joint Curriculum Task Force, National Science Foundation Don Gotterbarn-- Task Force for Revision of ACM Code of Ethics, East Tennessee State University Deborah Johnson--Chair, American Philosophical Association Committee on Computing and Philosophy, RPI Walter Maner-- Co-Chair, National Conference on Computing and Values, Bowling Green State University Dianne Martin-- Task Force for Revision of ACM Code of Ethics, The George Washington University Keith Miller-- Author and Consultant on Computer Ethics and Software Engineering, William and Mary College James H. Moor-- Pioneering Author in the field of Computer Ethics, Dartmouth College Donn Parker-- Author and Editor of Case Studies in Computer Ethics, SRI International Terrell Ward Bynum--Director, Research Center on Computing and Society, Southern Connecticut State University Video Tape No. 2: (45 minutes) WHAT IS COMPUTER ETHICS?--This video program provides a broad overview of the field of computing and human values as explained by major thinkers in the field. (Intended for classroom showing, as well as teacher preparation.) Video Tape No. 3: (45 minutes) EXAMPLES AND CASES IN COMPUTER ETHICS--In this video program, scholars and teachers present and explain examples and cases in computing and human values. Monograph No. 1: (110 pages) TEACHING COMPUTER ETHICS--This monograph examines teaching methods and strategies for integrating computer ethics into the curriculum. (The monograph is a component of the proceedings of the National Conference on Computing and Values, funded in part by National Science Foundation grants DIR-8820595 and DIR- 9012494). The editors are Terrell Ward Bynum, Walter Maner and John L. Fodor. Monograph No. 2: (142 pages) COMPUTING AND SOCIAL RESPONSIBILITY: A COLLECTION OF COURSE SYLLABI--This monograph contains detailed syllabi from a variety of courses on computing and human values. It was compiled and edited by Batya Friedman and Terry Winograd and published by Computer Professionals for Social Responsibility. For further information about this "Starter Kit", contact The Research Center on Computing and Society Southern Connecticut State University 501 Crescent Street New Haven, CT 06515 USA E-Mail: RCCS@SCSU.CTSTATEU.EDU Phone: (203) 397-4423 (Center & answering machine) Additional video tapes and printed materials on computing and human values, including additional components of the Proceedings of the National Conference on Computing and Values, are available from the Research Center on Computing and Society. For details, contact the Research Center. 5====================================5====================================5 From: lwerth@cs.utexas.edu (Laurie Werth) Subject: Software Engineering Netnews Debate >From wupost!darwin.sura.net!Sirius.dfn.de!rusmv1!ifistg !informatik.uni-stuttgart.de!bassler Thu Mar 12 14:59:00 CST 1992 In article <1992Feb28.134735.20440@afit.af.mil>, jcardow@galaxy.afit.af.mil (James E. Cardow) writes: |> |> What do I want from a software engineer? |> |> Ability to work, as part of a team. |> Ability to follow direction and eventually lead a team. |> Ability to produce a quality product |> Ability to recognize constraints |> Ability to estimate, accurately. |> Ability to work on schedule |> Ability to apply sound techniques to the application at hand. |> Ability to decide between available techniques given an |> understanding of the problem. |> I would like to add two more abilities: Ability to adhere to standards (e.g. those set out by IEEE); Ability to recognize every possibility of software reuse (and on the other hand to produce reusable software). |> Would it be better to have academics teach what they can teach well, |> technical skill? Stop looking to them to teach goal directed concepts |> like task management with schedule constraints. And start looking for |> a new way to develop team work, organization, and management. First, I think we have to admit that, as academic instructors, we don't even know how to teach technical skills--for at least one simple reason: you cannot teach technical skills without motivating your students to why these skills (e.g. producing a sound design from a requirements specification) are at all necessary. So even with the simplest matter we already have to deal with "goal directed concepts". Second, this doesn't mean we shouldn't teach technical skills or any of the other abilities mentioned above. The key point is to get the students motivated for what they are supposed to learn. And now, there are two preconditions to be met to achieve that goal: * The teachers themselves need to have appropriate experiences in large industry or research projects to understand the necessity for software engineering methods. As another poster (Roy T. Fielding) already pointed out, *there are* academic teachers who have these experiences. * The students have to experience the problems arising in projects without application of software engineering methods. At a workshop on software engineering education held last week here at the University of Stuttgart, FRG, the model practiced at the University of Bremen, FRG, was reported. They have groups of 15 - 20 students work on a single project for the whole time of their graduate studies (four to five semesters, 6 hours a week). Working in such a project should lay the basis for understanding software engineering ... To summarize, I would strongly plead for software engineering education at the universities, provided that there is sufficient experience available and room left to develop new ways of teaching. Nevertheless, I agree that we need "a new way to develop team work, organization, and management". In article <1992Feb28.180808.3832@riacs.edu>, lamaster@viking.arc.nasa.gov (Hugh LaMaster -- RCS) writes: |> |> * Without additional time to devote to Humanities, there is not enough |> time to provide a well rounded *EDUCATION*. |> This is a very important point. Software engineering is a social science in many areas--as opposed to other engineering disciplines. -- Thomas Bassler, Dept. of Software Engineering, University of Stuttgart, FRG >From sun-barr!ames!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu !think.com!wupost!m.cs.uiuc.edu!marick Thu Mar 12 15:07:54 CST 1992 rogers@ferranti.com (keith rogers) writes: >Do you >really think the percentage of graduating lawyers and doctors, who have >been trained in the real world problems they will encounter, is that >much higher than in engineering? I can only speak to veterinary medicine. At the University of Illinois, where my wife teaches, the entire senior year is spent rotating through clinical duties. In the large animal clinic, at least, students have direct responsibility for cases (under supervision, of course). I think all US vet schools follow the same pattern. It's very real-world. It's *painfully* real-world. It also does a dandy job of convincing students that the previous three years were necessary. Veterinary medicine has the advantage that, generally, the cases are short. In a rotation, a student can see several cases through from admission to release. I think that's important: several cases, real cases, followed through. We need to find a way to simulate that in software education. The problem, of course, is that our projects are typically much bigger and longer than treatment of a sick cow. The two common approaches are to simulate a large project in a semester, and to attach a student to part of a real project (co-op work). These are both valuable, but they do both suffer from being a single event that's supposed to teach generalities. How can we create more, but smaller, experiences? What kinds should they be? Brian Marick, marick@cs.uiuc.edu, uiucdcs!marick Testing Foundations: Consulting, Training, Tools. >From sdd.hp.com!think.com!rpi!batcomputer!cornell!rochester!kodak !ispd-newsserver!psinntp!norton!brian Thu Mar 12 15:10:12 CST 1992 lamaster@viking.arc.nasa.gov (Hugh LaMaster -- RCS) writes: > I will make a bald claim: there is no difference between software > engineering and other kind of engineering wrt to the engineering goals > listed in the original post. So, one may as well ask: > Should academics teach (any kind of) engineering? Excellent correction. My answer is "Absolutely not.". Asking some academic mathematician to teach software engineering is like asking a nun to teach sex education. That's not to say that no nun ever had anything interesting or true to say on the subject, but you might as well have english professors teaching the classes as "computer academics" who have never actually done any real software engineering. > An engineering degree in today's environment requires a five year program? > Why? > * Without five years, there is not enough time to cover all the math > required. Today, computer engineers can benefit from knowledge of > abstract algebra, number theory, mathematical logic, measure theory, > probability theory, > --etc-- > a far cry from the basic calculus which served most engineers 30 > years ago. This concentration on math for software engineers is pure silliness. Unless you are going into applications that require heavy math (like graphics for example) you wilkl never use 95% of the math you learn in college. The same could be said of business, accounting, chemistry, and what have you. If you are doing software for businesses, it is useful to know something about business. If you are doing programming for biologists, it is good to know some biology. Math is nothing special in this regard...beyond high school freshman algebra anyway. The reason we see such a math emphasis in the curriculum is that the unioversities are full of mathematicians pretending to be software engineers and they inject their unfounded prejudices into the curriculum. > * Without five years, there is not enough time to cover all the physics > required. Most programs will not cover the E&M material in, say, > Schwartz's "Principles of Electrodynamics" until the Junior year. Not > to mention QM and solid state physics. What does a software engineer need with physics? I'm not saying that it is bad to know and heaven knows I took plenty of it when I was in school, but I look at it as more of a "well-roundedness" issue than as one of being necessary to become a good software engineer. I would have probably benefitted just as much by taking a bit more history, english, or accounting. > * Without additional time to devote to Humanities, there is not enough > time to provide a well rounded *EDUCATION*. Which leads to the question of whether the humanities programs for undergraduates are worth the time. I certainly think that the SUBJECTS are worthy ones, but the way they are taught in such a fustian manner that it is amazing that anyone has an interest in the subjects after taking them. > Instead of tenured lifetime academics, the engineering department > should try to arrange to have as many as possible practicing engineers > on temporary assignment teach in the program as possible. Politically, this is dynamite (but a good idea). Having such people around the department would provide a constant challenge to the knowledge of the academics that they generally can't answer. Plenty of these academics can't write a "Hello world" program that works. Such challenges to authority are very dangerous for them, but I strongly think that they should be challenged in this way. > I think this > would help greatly bridge the cultural gap. Of course, in order to attract > practicing engineers, it will require paying them rather more than junior > instructors usually get today :-) You get what you pay for. Another bit of political dynamite is that the best of these engineers don't have advanced degrees, which according to the academic community means that they can't have anything very interesting to say. That's another myth that needs to be demolished. > If the pure Science and Humanities > departments don't like, I guess they will have to be reminded about > supply and demand and the value of the "tenure" fringe benefit they > receive :-) Hold on...why should the fact that one has some real experience in a field automatically mean that he should be ineligible for tenure? Why the double standard? --Brian -- -- Brian K. Yoder (brian@norton.com) - Q: What do you get when you cross -- -- Peter Norton Computing Group - Apple & IBM? -- -- Symantec Corporation - A: IBM. -- -- >From sun-barr!ames!agate!anarres.Berkeley.EDU!bh Thu Mar 12 15:12:39 CST 1992 brian@norton.com (Brian Yoder) writes: > Plenty of these academics can't write a "Hello world" program that works. C'mon, if we're going to argue at that level, one could reply that plenty of industrial engineers don't know how to teach. Many of my academic colleagues came to the university after long and distinguished programming careers in industry, and many continue to work as consultants for industry. I know I spent ten years working as a programmer before I got interested in education. Teaching is a lot harder than programming, I find. Any idiot can program. I'm a good programmer, I think. But I'm challenged by teaching. While we are being outrageous, let me suggest that software engineering is overrated anyway. All the really worthwhile programming projects that really advanced the state of the art were done by one or at most two people who were accomplished hackers, not software engineers. My standard example of this is that the step from nothing to VisiCalc (one hacker) was a much bigger step than that from VisiCalc to Lotus 1-2-3 (thousands of software engineering drones). One person wrote EMACS. Two people wrote Unix. And so on. I'm deliberately saying this offensively in order to offend Mr. Yoder, to get back at him for offending me. But I do believe this, I think. >From wupost!zaphod.mps.ohio-state.edu!pitt.edu!drycas.club.cc.cmu.edu !sei.cmu.edu!cert!netnews.upenn.edu!rutgers!sun-barr!olivea !spool.mu.edu!snorkelwacker.mit.edu!linus!linus!mitre.org!troyer Thu Mar 12 15:13:23 CST 1992 In article bh@anarres.Berkeley.EDU (Brian Harvey) writes: > While we are being outrageous, let me suggest that software engineering > is overrated anyway. You may have sited evidence that small teams of very good engineers/programmers are more efficient at creating software systems. I won't argue with that. However, I would submit that software engineering is a heck of a lot more than programming. In fact, programming is the smallest part of it. Identifying the problem to be solved and figuring out a way of determining whether the proposed solution adequately solves that problem is what software engineering (or any engineering discipline) is all about. "Software engineers" frequently run into trouble because they really don't understand the problem to be solved as the users see it. Anyone with some software knowldege who can teach problem understanding, whether academic or not, is qualified to teach software engineering. Those who can't, aren't. Tom Royer >From sun-barr!ames!network.ucsd.edu!usc!rpi!batcomputer!cornell!rochester !cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!mse!jsm Thu Mar 12 15:14:00 CST 1992 In article , bh@anarres.Berkeley.EDU (Brian Harvey) writes: |> |> While we are being outrageous, let me suggest that software engineering |> is overrated anyway. All the really worthwhile programming projects that |> really advanced the state of the art were done by one or at most two |> people who were accomplished hackers, not software engineers. My standard Ok, I'm give the fact that you are being outrageous to make a point, but I think the fundamental difference of opinion comes 2 lines later. The purpose of software engineering is NOT to "advance the state of the art." The purpose of software engineering to project copmuter science techniques into the "real" world of costs, estimates, schedules, and profit. If you can meet a budget, make your estimates, turn a profit AND advance the state of the art at the same time, you are wasting your time typing on these bboards. Go off and make your billion and I'll come work for you. -- Jim Murphy jsm@mse.cmu.edu MSE Program, SEI Carnegie Mellon University >From sun-barr!ames!haven.umd.edu!darwin.sura.net!udel!rochester!kodak !ispd-newsserver!psinntp!norton!brian Thu Mar 12 15:15:03 CST 1992 bh@anarres.Berkeley.EDU (Brian Harvey) writes: > brian@norton.com (Brian Yoder) writes: > > Plenty of these academics can't write a "Hello world" program that works. > C'mon, if we're going to argue at that level, one could reply that plenty > of industrial engineers don't know how to teach. But teaching isn't their job. The academics are supposed to both know the material and know how to teach it. A great many of them (in my personal experience) are missing one or both of these skills. > Many of my academic colleagues came to the university after long and > distinguished programming careers in industry, and many continue to work > as consultants for industry. I know I spent ten years working as a > programmer before I got interested in education. Three cheers for them. They are not the problematic folks I am talking about. > Teaching is a lot harder than programming, I find. Any idiot can program. > I'm a good programmer, I think. But I'm challenged by teaching. My experience has been that the biggest determinant of who will be a good programmer is their level of interest. The same can be said for teachers as well. > While we are being outrageous, let me suggest that software engineering > is overrated anyway. All the really worthwhile programming projects that > really advanced the state of the art were done by one or at most two > people who were accomplished hackers, not software engineers. My standard > example of this is that the step from nothing to VisiCalc (one hacker) > was a much bigger step than that from VisiCalc to Lotus 1-2-3 (thousands > of software engineering drones). One person wrote EMACS. Two people > wrote Unix. And so on. I don't disagree. When I use the term "software engineering" I don't mean it in the stale academic sense, but in the real-world sense...the creation of software. I would say that those "hackers" are just great software engineers. > I'm deliberately saying this offensively in order to offend Mr. Yoder, > to get back at him for offending me. But I do believe this, I think. Why do you think this is offensive to me? I agree with 3/4 of it. None of what you wrote contradicts the idea that universities are packed with professors whose main interests are research grants, campus politics, and getting tenure rather than becoming and staying competent in the skills necessary to do a good job at teaching students about software engineering (or hacking or whatever). --Brian -- -- Brian K. Yoder (brian@norton.com) - Maier's Law: -- -- Peter Norton Computing Group - If the facts do not fit the theory,-- -- Symantec Corporation - they must be disposed of. -- -- - -- >From uunet!psinntp!ncrlnk!ncr-sd!SanDiego.NCR.COM!!jim Thu Mar 12 15:16:51 CST 1992 In article <1992Mar03.055255.16528@norton.com> brian@norton.com (Brian Yoder) writes: >lamaster@viking.arc.nasa.gov (Hugh LaMaster -- RCS) writes: > >> I will make a bald claim: there is no difference between software >> engineering and other kind of engineering wrt to the engineering goals >> listed in the original post. So, one may as well ask: I read an interesting article 6-12 months ago, I believe it was in "Communi- cations of the ACM". The writer pointed out that Computer Engineering is quite different from other "Engineering" fields because we often don't use mathematical or logical techniques for designing software. We use a trial and error method for coding which depends mostly on experience for being correct or efficient the first (or subsequent) time it's coded. The article cited a few interesting examples where using mathematical techniques for solving an algorithm, rather than just "coding it up", resulted in a better, if counter-intuitive solution. >> Should academics teach (any kind of) engineering? > >Excellent correction. My answer is "Absolutely not.". Asking some academic >mathematician to teach software engineering is like asking a nun to teach >sex education. That's not to say that no nun ever had anything interesting >or true to say on the subject, but you might as well have english professors >teaching the classes as "computer academics" who have never actually done any >real software engineering. Usually academic mathemeticians teach math and academic computer scientists teach computer science. I can't speak for other engineering fields, but when it comes to computers I don't know of any program that actually teaches "computer engineering". They teach theory, math, algorithms (e.g., automata theory), and a few techniques. I can't remember any class that was designed to teach me how to plan a project, scope it out, spec it, code it, test it, and deliver it. I agree that academics shouldn't teach computer or software engineering. I also don't think they do now. I believe we need to have someone teaching engineering who knows what engineering is. >> An engineering degree in today's environment requires a five year program? > >> Why? > >> * Without five years, there is not enough time to cover all the math >> required. Today, computer engineers can benefit from knowledge of >> abstract algebra, number theory, mathematical logic, measure theory, >> probability theory, >> --etc-- >> a far cry from the basic calculus which served most engineers 30 >> years ago. > >This concentration on math for software engineers is pure silliness. Unless >you are going into applications that require heavy math (like graphics for >example) you wilkl never use 95% of the math you learn in college. The same >could be said of business, accounting, chemistry, and what have you. If you >are doing software for businesses, it is useful to know something about >business. If you are doing programming for biologists, it is good to know >some biology. Math is nothing special in this regard...beyond high school >freshman algebra anyway. The reason we see such a math emphasis in the >curriculum is that the unioversities are full of mathematicians pretending >to be software engineers and they inject their unfounded prejudices into the >curriculum. After I read the ACM article I mentioned above I started re-thinking my position on this. If math and theory is taught as generalized engineering techniques it may be worthwhile to learn more of them. I remember a mechanical engineering friend of mine in college had to take lots more math than I needed. Does anyone know how much math other engineers (mechanical, chemical, bio, etc) use on a general, day-to-day basis? >> I think this >> would help greatly bridge the cultural gap. Of course, in order to attract >> practicing engineers, it will require paying them rather more than junior >> instructors usually get today :-) > >You get what you pay for. Another bit of political dynamite is that the >best of these engineers don't have advanced degrees, which according to the >academic community means that they can't have anything very interesting to >say. That's another myth that needs to be demolished. The only problem with paying them more is that Universities only do teaching as a secondary priority. Their first priority is what really pays the bills - government research. For this, they need academics. A tenured professor may be a poor teacher, but that part of his or her job brings in much less money than the research side. An engineer temporarily on staff can only be supported by the students tuition. >> If the pure Science and Humanities >> departments don't like, I guess they will have to be reminded about >> supply and demand and the value of the "tenure" fringe benefit they >> receive :-) > >Hold on...why should the fact that one has some real experience in a field >automatically mean that he should be ineligible for tenure? Why the double >standard? Because since he has REAL experneice, he doesn't need tenure :-) Jim Ruehlin >From usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!udecc.engr.udayton.edu !blackbird.afit.af.mil!galaxy.afit.af.mil!jcardow Thu Mar 12 15:21:16 CST 1992 Since I started this discussion (in a really bad mood for a Friday A.M.) it has taken some really interesting turns and I would like to readdress a few points that were lightly touched on. Contribution of single individual and small group. No argument on the level of contribution, but what did the "army of drones" contribute. Stability? Dependability? Many other factors that make the difference between marvelous prototypes and successful projects? I think it is fantastic that individuals, working autonomously or in small groups generate the unique ideas that spur new ways of doing things. The "skunkworks" that created the SR-71 and several other great planes were fantastic, but if the next time I boarded an aircraft it said "build by one great tinker" I would probably opt to walk. Now this is one great exageration, but the point is I don't need engineering to be inventive, I need engineering for practicality. Necessity of math in software engineering. When I was completing my B.S. in comp sci, I questioned the validity of the Calc and other math courses required in the program. Now I have two wishes, 1) that I had taken much more math, and 2) that the people teaching math could have presented useful applications. I think there is a tremendous need for math maturity and math as a tool to draw on for *engineering* systems. Teaching software engineering. One of todays post said that project skill were not being taught in colleges, I agree to some extent, unfortunately some of the course are supposed to be teaching them. That was the purpose for the original post. These technical/management skills are necessary, are supposedly covered by course, but are not coming across. For the same reason I had difficulty justifying math, the value is not presented. (Before you assume I'm dumb as a rock, my math grades were very high, I just couldn't see the usefulness). Finally, back to the original question of who should teach software engineering. I still don't believe academics (let me define that better--life-long students and those with only limited experience in the full range of software activities)Yes, I did make a gross generalization in the first post. Yes, there are some excellent, scarred survivors of industry teaching software engineering. Yes, teaching is one h... of a lot harder than developing code. How about some solutions? Or some directions to think about? Let me suggest some. One poster said "you get what you pay for" in discussing the disparity between teaching salaries and commercial salaries. Their point was pay people more to incentivize them to teach. How about a different approach. Industry and government--you get what you pay for. If you want higher quality graduates that understand the reason for doing things in a *engineering* way, pay for it! What is wrong with industry underwritting the additional salary to get some top notch people to teach the cap-stone type software engineering courses in undergrad programs or the core in grad programs. Looks to me like a way to influence the quality of the product (students) and can't damage recruiting efforts? Co-op efforts. The five year degree (as a starting point) with co-op time makes a lot of sense. Provided the co-op time is made meaningful, not an adventure in "how I spent my summer vacation." Professional degrees in the vain of law and medicine? Hum, that was a different thought. Maybe a more productive use of thesis work, coupled with internships wouldn't be a bad approach. I'm not sure that is really the solution, but it bears some extensive thinking. Now how about some other alternatives: Structure the knowledge and the appropriate teaching level. In the government research programs are categorized from basic research to those areas ready for application on future systems (6.1 to 6.4). Perhaps a similar skill level for courses are necessary. Tier 1: Foundations: math, science, language (english, what ever--communication skills.) Tier 2: Implementation skills: programming languages, design methodologies, testing approaches (esp. testing approaches). Tier 3: environment skills (bad choice of terms, but I'm stuck). Operating system theories, management approaches (estimating, organization) Tier 4: domain: In something like this, the best skills of the instructor could be used. The liberal arts are essential in tier 1. What I have termed academics are essential in tier 2 (given that they apply the skills of tier 1 to tier 2 information). Academics again fit well in tier 3, again with the stipulation that tier 1 and 2 skills are applied. Finally, tier 4 is where my concern started. This is the point where the co-op ideas and the professional degree approach, and the use of veterans of software bring the material together. May be tier 4 shouldn't be more than introduced at the undergraduate level. But if it doesn't build and demonstrate concepts from tiers 1-3 with bounds of real-world, then it misses the mark. Just a thought. I was sitting in the back of senior level course in software engineering course (undergraduate), watching a very skill instructor describe the software crisis. He used excellent examples. His stories were great, well supported, real. I noticed a student in front of me really seemed confussed. Finally the student asked "how can software still be in a crisis twenty-four years after the term was coined?" When I realized that only the instructor and I were alive *that long ago* I could see the students concern. The point is the stories aren't enough. The foundation for the solution needs to be built, then reinforced with a sprinkling of "this is where I went wrongs" and a healthy dose of "here is a better way" That is if we really want to *get what you pay for* from software engineering education. By the way, I'll still stick to my list of "what do I want from a software engineer" (plus those added by Bassler) if for nothing else than to have some requirements defined for the end product I say I need. Jim Cardow Instructor of Software Engineering Air Force Institute of Technology Still no answers, still asking questions. Thanks for many excellent comments. >From usc!rpi!news-server.csri.toronto.edu!ccs-server.QueensU.CA !qucis.queensu.ca!dalamb Thu Mar 12 15:24:38 CST 1992 I've been following this discussion and will be saving a few of the ones I consider especially interesting in the comp.software-eng FAQ file on education. I'm afraid, however, than I've left out several messages due to what I consider too high a flame content. One thing I'd like to see more of is comments that lead to some possible action to improve things. Here's (a caricature of) the opinions I've seen so far. Opinion: Profs can't teach anything very well; they spend their time on research, politics, and self-preservation. Comment: The best summary of this I can recall is the "ProfScam" book mentioned at the end of this article. Action: I can't guess what the readership of this newsgroup could do to correct such a situation, besides, I suppose (a) organizing some massive lobby, (b) hunting for those (few?) profs unaffected (or less affected) and trying to support their work as much as possible (c) ignore the output of universities and train s.e.'s yourself. Opinion: People who teach s.e. should have practical experience, such as prior industrial experience and continued consulting. Comment: Sounds good. Actually, most engineering faculties are quite happy to encourage consulting - and for accreditation they usually require a majority of the curriculum development be overseen by profs who are also professional engineers. For a c.s. department in a Science or Arts&Science faculty it can be a bit harder to argue. Action: If you're in industry, find CS/SE profs to hire as consultants! If you're a p.eng (or l.p.e or whatever your jurisdiction calls it), work with your local professional organization and nearby universities to work out rules for accrediting a software engineering program (good luck; it's probably going to be a hard job). Opinion: Encourage people from industry to teach. Comment: Sounds good. There's the salary issue, of course. When I was just starting out as a prof, after a particularly painful interaction with some students, I calculated I could have literally doubled my salary by accepting the startup company offer I'd just turned down (had to calcualate because of conversion between US and Canadian dollars). So what's the incentive to leave industry to teach? [Mine was a feeling of vocation, in the old-fashioned Christian sense] Action: If you're in industry, try to work out some way to assist a nearby university. Some are quite happy to hire "adjuncts" to teach occasional courses. A Toronto company, as part of its recruiting efforts, gives talks on what its real-world projects are like to undergraduates. Opinion: Industrial types probably don't know how to teach. Comment: Neither do many beginning profs. Action: There might be room for a cooperative arrangment, where some prof chosen for pedagogical skills helps the aforementioned industrial type get started. I suppose we ought to do this for "regular" academics too - but there's a real issue of where the "resources" (primarily people time) are to come from. Opinion: What do you mean, "spend too much time on research"? The only good educator is someone solidly engaged in research. Comment: This is a common, though not universal, attitude among academics these days. It has some justification: how can someone teach in a rapidly changing field if they aren't keeping up with the latest stuff? However, does one really need to be originating advanced work in a very narrow field to teach undergraduates properly? Action: (a) If you agreee, I guess there's no problem (!) (b) If you disagree, I suppose you could try to convince the profs you know that they're wrong. Try to understand the current pressures on universities if you want to have good levers to move them, though. Here's the "ProfScam" reference: Author: Sykes, Charles J., 1954- Title: ProfScam : professors and the demise of higher education / Charles J. Sykes. Published: Washington, D.C. : Regnery Gateway ; New York, NY : Distributed to the trade by Kampmann & Co., c1988. Description: x, 304 p. ; 24 cm. Subjects: Education, Higher--United States. College teachers--United States--Attitudes. Notes: Includes index. Bibliography: p. 265-292. ISBN: 0895265591 >From uunet!mole-end!mat Thu Mar 12 15:26:41 CST 1992 In article <1992Mar6.114027.26324@news.cs.indiana.edu> mchui@mango.ucs.indiana.edu (Michael Chui) writes: > In article <1992Mar6.090126.15140@mole-end> mat@mole-end writes: >> ... Using PhD and post-grad students to teach basic CS/SE materials is >> a bad move, even though it's long-established. ... We *do* need >> people generating new ideas. We also need people educating, and at the >> undergrad level there's too much room for conflict. > The traditional academic activities of research and teaching > (and service) are related by symbiosis, not conflict. Research keeps one's > teaching current, and vital. Teaching provides additional insight into > one's research. Service keeps both relevant. I have an urge to pick this apart piece by piece, but maybe a strategic view would show a larger flaw in it. Let's get another statement: In article <1992Mar9.150233.2971@qucis.queensu.ca>, dalamb@qucis.queensu.ca (David Lamb) writes: > Opinion: What do you mean, "spend too much time on research"? The > only good educator is someone solidly engaged in research. > Comment: This is a common, though not universal, attitude among > academics these days. It has some justification: how can > someone teach in a rapidly changing field if they aren't > keeping up with the latest stuff? However, does one really > need to be originating advanced work in a very narrow field > to teach undergraduates properly? This is closer to the mark. But try this on for size: The research done by academics only matters if industry adopts it. Industry will not adopt new methods just because BSEs and MSEs are trained in them. Those BSEs and MSEs will lack the project experience, the management skills, the credibility, and the seniority to introduce new methods. New methods are introduced by people who go directly to management, by the DeMarcos and the Pirbhais, by the Mellors and the Codds and the Yourdons. Therefore, `currency' among undergrad and basic theory instructors should be industrial currency and what lies just ahead of it. But what the `basic theory' instructors MUST do is give their students the INSIGHT and UNDERSTANDING that the theory (and methods and practices ...) provide, and not just their forms. To do this, they must be extraordinary instructors, especially since most of their students are not prepared to use `tools of thought' in this way. An anecdote on this last point (and one of my favorite stories): On the first day of lecture in my freshman physics class (Newtonian mechanics), the professor (an institution at the school) looked out at his hundred or so students, knowing full well that two thirds of them had come from Stuyvesant or Bronx Science (two out of the dozen best science HSs in the country), and that virtually ALL of them had taken physics in high school, and that at least two thirds of them had taken the NYS Regents exam in physics. He looked out over the group, and began: ``Gentlemen, I would like to welcome you all to your first course in Physics.'' He paused, as if considering. ``How many of you have had Physics in high school? Those of you who have had Physics in high school, please raise your hands ....'' He gazed about the room, then grinned evilly. ``To those of you with your hands raised, I would ESPECIALLY like to welcome you to your first course in Physics.'' He meant every word, and more. In that course we learned how to think about a problem on its own terms, how to use the `theory' to really understand what was going on, how to make the `theory' a tool of thought. (First time I was ever PROUD of a `C' ...) He's retired now, and I have nightmares about what the students are doing without him. How many are still asking if it's warmer in the summer than it is in the Catskills? without him. He had no need to be `current'; the last change in Newtonian mechanics occurred after Oliver Heaviside showed that vectors could be used instead of quarternions. Granted, neither SE nor CS are that mature, but the subjects taught in the first year or two are almost that mature. Discrete math and Logic,Automata&Languages certainly are, and the basics of good coding (my diatribes notwithstanding) have been solid for fifteen years now. And a students first years should be spent learning how to THINK in terms of the problems that the discipline gives. Thinking about the problems themselves comes a little later. (About the most volatile subjects today for the first three years are hardware architecture and non-procedural or mixed programming models, and those are hardly basic courses.) -- (This man's opinions are his own.) From mole-end Mark Terribile uunet!mole-end!mat, Somewhere in Matawan, NJ >From qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!pdxgate !rigel!warren Thu Mar 12 15:28:46 CST 1992 >Hold on...why should the fact that one has some real experience in a field >automatically mean that he should be ineligible for tenure? Why the double >standard? > It's not clear to me why someone with "real" experience in the field automatically has anything of interest to say simply by virtue of the fact he/she has had some "interesting" experiences. That's not to say that field experience automatically disqualifies you, but it certainly isn't enough - I've seen far too many practitioners who were totally incapable of generalizing any of their experiences. Believe it or not, education isn't simply war stories or "telling the students what it's gonna' be like when they graduate". When I quit hearing from my clients about overrun budgets, buggy software and maintenance nightmares, I might conclude that ten years in the trenchs equals a PhD, but I won't hold my breath. >From wupost!uwm.edu!ogicse!plains!jazimmer Thu Mar 12 15:31:32 CST 1992 Several writers in this thread have said that software engineers require some practical training. Suggested ways to do this have included putting practitioners in the classroom, sending students out on coop, following the legal or medical models, and following the model of other engineering education. With five years in the real world and fifteen years as a teacher, I couldn't agree with the goal more. However, none of the proposed solutions will work. To put practitioners in the classroom is to put practitioners where practice doesn't fit. They will be forced to lecture about the process just like other teachers. Sending students out on coop suffers because it is difficult for employers to find appropriate things for students to do and because most are more concerned with their own problems than with educating the next generation. In the medical model, interns practice on real patients under the supervision of their teachers who continue to practice while following a teaching career. This model works for medicine because the problems which students are given to solve do not require a minimum of several weeks effort and because a student's judgement can be quickly reviewed by his or her supervisor. Neither of these things is true in the world of software. In the legal model, students work on case histories. This is similar to what an intern does, but the case histories have been solved at a previous time. This model works in law because students do not need to see patients -- they can work on their solutions in libraries. Like the medical model, the problems do not take so long to work out as those in software engineering. While the legal briefs that show a sample solution are difficult to read, they are easier than current practice has made source code or design documents. The legal model is the best yet, but it doesn't quite fit the needs of software engineering education. In the engineering model, a practitioner's activity is broken down into small steps which students learn to solve with traditional educational methods. This is what most hardware engineers and software engineering researchers expect to happen to software engineering. Methinks, to do this we must standardize and to standardize we must stop changing so fast and to stop changing so fast we must stop being the leading edge of adaptability. In projects where embedded software runs a machine, for example, we must act more like hardware engineers and say "let somebody else adapt to this change." Of course, when we have done these things our value will go down. Before firing off a rebuttal of the above paragraph, consider another reason why the engineering model is not quite what we want. I have read (unfortunately, I have forgotten where -- could somebody provide the reference?) that the training of American engineers differs from those of Europe and Japan in that those countries include some practical experience in their training programs. Our production engineers aren't doing so hot -- could this be part of the reason? Even if I am wrong and the engineering model is just exactly what is needed, there is the possibility that practical training would enhance that model if we could think of a reasonable way to do it in this country. (Do the Europeans and Japanese have a reasonable way?) Practical training is what provides skills. Classrooms provide knowledge. Software engineers need both. So, here is my suggestion. Let's make our own educational model. (Like we have made our own everything else.) The model should include practical training. Let's do it like the doctors but not in real time and not on all possible types of work. In particular, each Computer Science department could take over the maintenance of some real software for which maintenance work is not time critical. (You all have such work in your companies -- it isn't being done. Let the profs do it with student labor.) What? You say that maintenance is not good training? Note that researchers in the field define maintenance as any work on the product after the customer has taken possession. Consider these facts, most of the software dollar goes to maintenance, most newcomers are given maintenance work to train them and, in the software world, maintenance isn't so very much different than development. To illustrate the final point consider this story. A software engineer was given a project which, it was estimated, would take a man-year to complete. After the first day, her boss asked her how it was coming. "I'm done!" she said. "I instantiated the null program and wrote a manual to describe it. Now its a maintenance problem." Of course, the suggestion has practical difficulties: projects would need to be limited to those which run in environments available at universites, projects would typically be much bigger than those handled by doctors and professors would have to learn something about teamwork and quality control. Because there are many possible projects, not being able to work on 80% of them isn't a difficulty. That professors would need to learn about teamwork and quality control isn't a difficulty either -- it's an opportunity to teach the rest what some already do know. The real stickler is, as it always was, problem size. This can be limited somewhat by considering only maintenance work, but the maintenance problems that are short are also not so very instructive. So, the size difficulty remains. However, because the problem is not going to be done in real time, more of the problem-solver's effort can go into writing about what she has done so that another can take up the work where she left off. This isn't the way it is out there, but who would say the practice won't be a very good experience? J. Adrian Zimmer (701) 777-4133 Dept. Of Computer Science jazimmer@NoDak.plains.edu University of North Dakota ** Where there's a bond, ** Grand Forks, ND 58202-8181 ** there's a way! ** >From sun-barr!olivea!spool.mu.edu!yale.edu!qt.cs.utexas.edu !zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att !rutgers!rochester!rit2!rit!mjl Thu Mar 12 15:32:40 CST 1992 In article <15750@plains.NoDak.edu>, jazimmer@plains.NoDak.edu (Adrian Zimmer) writes: |> Sending students out on coop suffers because it is difficult for employers |> to find appropriate things for students to do and because most are more |> concerned with their own problems than with educating the next generation. I'll let you all in on a secret: Those of us with co-op programs, who are fortunate enough to teach upper-division students bringing personal, practical experience to bear on the topics at hand, certainly hope that the rest of you subscribe to the opinion above -- it keeps the competition down. Establishing a co-op program and convincing prospective employers that your students have something valuable to contribute is difficult (all the more so if your students do *not* have anything to contribute! :-). However, once a reputation is established, a truly fascinating symbiosis evolves between academia and industry, to the benefit of students, employers, and those professors interested in enhancing their students' professional careers. We've had few problems with employers who don't find meaningful projects for co-ops. And the fact that these employers are concerned with their own problems is *wonderful* education for the next generation: they see the real risks and costs, and that the stakes are high (whereas in courses the stakes are kept low on purpose). After 15 years here, it's hard for me to imagine what it must be like to teach software development concepts to juniors and seniors who have no experience base to draw upon. -- Mike Lutz Department of Computer Science Rochester Institute of Technology Rochester, NY 14623-0887 USA +1 (716) 475-2472 mjl@cs.rit.edu 6====================================6====================================6 From: csesun1!jalote@kalyan.ernet.in (pankaj jalote) Subject: A new text book on Software Engineering from Springer Verlag New York. I have been teaching group project based software engineering course for over 6 years - first at University of Maryland at College Park, then at IIT Kanpur. I found that I was changing books pretty much every time I taught, as I was not satisfied with the available text books. Based on my perceptions about the needs of such a course, I have developed a text book entitled "An Integrated Approach to Software Engineering". I believe that the book will be of interest to faculty teaching software engineering courses. I am briefly describing here the approach taken in the book. Pankaj Jalote (jalote@kalyan.ernet.in) --------------------------------------------------- Book Title: AN INTEGRATED APPROACH TO SOFTWARE ENGINEERING Author: Pankaj Jalote Publisher: Springer Verlag, New York. This book offers an Integrated Approach to Software Engineering. In this book the different topics are not covered in isolation. A running case study is employed, which is used through out the book, illustrating the different activities of software development on the same project. Most of the major outputs of the project, like the project plan, design document, code, test plan, test report etc. are shown for the case study. Integration is further achieved by combining software metrics with the different development phases, instead of having a separate chapter on the subject. It is recognized that metrics are used for controlling and assessing a software project and are employed throughout the life cycle. In the book, for each phase, relevant metrics and their use is discussed in the chapter for that phase. This conveys the right idea that metrics is not really a separate topic, complete in itself, but is integrated with the different activities of software development. Similarly, for each phase, quality assurance activities and the control activities that need to be performed while the activities of that phase are being done are described in the chapter for the particular phase. The sequence of chapters is essentially same as the sequence of activities performed during software development. All activities, including quality assurance and control activities, that should be performed during a particular phase are grouped in one chapter. This is particularly useful for a project-based course in Software Engineering, in which the students and the instructor can follow the chapters in the order given both in the lectures as well as in the project. FOR DESK/EXAMINATION COPIES: Please send a request on department stationary to (or try calling her at 212-460-1500): Springer-Verlag; Attn: J. Jeng; 175 Fifth Avenue; New York, NY 10010. Fax: 212-473-6272 TO ORDER: call 1-800-SPRINGER (last R is ignored) 7====================================7====================================7 From: ncc13 Subject: The 13th National Computer Conference & Exhibition THE 13TH NATIONAL COMPUTER CONFERENCE & EXHIBITION King Abdulaziz City for Science and Technology (KACST) and the Saudi Computer Society will host the 13th National Computer Conference and Exhibition in Riyadh, on 27/5-2/6, 1413 AH, 21-26 November, 1992 AD. This conference is a continuation of the previous 12 national computer conferences held in the Kingdom of Saudi Arabia since 1394 AH, 1974 AD. The General Conference Theme is: INFORMATION TECHNOLOGY TRANSFER The conference Organizing Committee would like to extend its invit- ation to all scholars to submit original research papers for consid- eration under the following topics: MAIN TOPICS: ----------- A - HUMAN ASPECTS 1. Human Computer Interaction 2. Training 3. Legal Aspects 4. Social Aspects 5. Computer Literacy and Education 6. Special Interest Groups B - RESEARCH AND DEVELOPMENT 1. Information Industries 2. Tools and Infrastructures 3. Role of Research 4. Planning and Management Papers on the following topics can also be submitted: 1. Computer Networks 2. VLSI 3. Systems Architecture 4. Software Engineering 5. Artificial Intelligence 6. Data Bases The deadline for submission of the full text of the papers is 26/12/1412 AH (27 June 1992 AD) The notification date for acceptance of refereed full papers is 10/4/1412AH (6 October, 1992 AD). Five copies of each paper should be mailed to the following address: Chairman of Research Committee, The 13th National Computer Conference Directorate of Information Systems King Abdulaziz City for Science & Technology (KACST) P.O. Box # 6086, Riyadh 11442, Saudi Arabia A paper should include an abstract of not more than 200 words, and the paper length, including diagrams and tables, should not exceed 15 single-spaced A4 pages. Margins should be approximately 3 cm and the paper should be printed on a high quality printer. References should be numbered in the following format: -{Number}, author name, title, journal or publisher, volume, number, place and date, page numbers. For more information, please contact: Tel: (966-1) 481 3273 Fax: (966-1) 488 3118 E-Mail: NCC13@SAKACS00.BITNET End=================================End=================================End %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % % Managing Editor: Pen-Nan Lee % % fase@cs.uh.edu % % % % % % % % % % % % % % Organizing Committee % % % % Keith Pierce % % University of Minnesota, Duluth % % Currently on leave at the Software Engineering Institute % % Carnegie Mellon University % % Pittsburgh, PA 15213-3890 % % Telephone: (412)268-8145 % % Fax: (412)268-5758 % % Email: krp@sei.cmu.edu % % % % % % Laurie Werth % % Dept. of Computer Science % % Taylor Hall 2.124 % % University of Texas at Austin % % Austin, Texas 78712 % % Telephone: (512) 471-9535 % % Fax: (512)471-8885 % % Email: lwerth@cs.utexas.edu % % % % % % Pen-Nan Lee % % Dept. of Computer Science % % University of Houston % % Houston, TX 77204-3475 % % Telephone: (713)743-3342, 743-3350 % % Fax: (713)743-3335 % % Email: pnlee@cs.uh.edu % % Email: fase@cs.uh.edu % % % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%