%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Forum for Academic Software Engineering % % (The Electronic Version) % % % % Volume 2, Number 3, February 20, 1992 (FASE No. 4) % % % % _____________________________________________________________________ % % % % 1 Computer Science/Software Engineering Split? % % % % 2 Teaching Testing % % % % 3 Resources For Teaching Testing % % % % 4 Expanding The Pipeline % % % % 5 Software Engineering Education At SIGCSE Technical Symposium % % % % 6 FASE Mailing List % % % % 7 Undergraduate Computer Science Curriculum, Multi-term, Multi-class % % projects, etc. % % % % 8 The IEEE CS First Annual National Programming Contest % % % % 9 Drexel Position Announcement % % % % 10 A New Textbook From Aksen Associates/Irwin Publishing Company % % _____________________________________________________________________ % % % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 1================================1================================1 Subject: COMPUTER SCIENCE/SOFTWARE ENGINEERING SPLIT? From: Lionel Deimel The relationship of software engineering to computer science continues to be a topic of controversy. On one hand is the abstract matter of whether one discipline is properly a part of the other or whether the two are separate fields whose spheres interact. Of more practical consequence is the question of where software engineering will eventually find its home in academe. Will departments of software engineering apart from--and in some sense in competition with--departments of computer science become commonplace? Many of you probably heard Bill Wulf's talk at last year's luncheon of the 22nd SIGCSE Technical Symposium in San Antonio. Although Wulf was supportive of education for software engineering, he warned against software engineering's going its own way, apart from computer science. I think I detected a certain territorial defensiveness in this speech, but attendees may have other interpretations. In any case, Wulf recently published some remarks on the same topic. He expresses many of the same ideas as in his SIGCSE address in "SE Programs Won't Solve Our Problems" ["Computing Research News," v. 3, n. 5, p.2, Nov. 1991]. In his essay, Wulf mentions the abstract question of the relationship between software engineering and computer science. He doesn't dwell on it, except to say that analogies to other science and engineering disciplines are specious. He admits that computer science needs reform if it is to prepare future computer professionals, however. Computer science must "shed its inward focus" and show its usefulness to applications, he contends. His argument for not achieving "reform" through instituting university software engineering programs, however, is very pragmatic, even political. Establishing a separate software engineering curriculum, says Wulf, will hinder reform of computer science and dilute the influence of the computing community on public policy. Norm Gibbs, director of the Products & Services Division of the Software Engineering Institute and formerly head of the SEI's Education Program, addresses similar issues in "Software Engineering and Computer Science: The Impending Split?" ["Education & Computing," v. 7, n. 1-2, pp. 111-117, 1991]. Gibbs, a computing educator--I originally wrote "computer science educator"--of long standing, shares some of Wulf's concern about fragmenting the computing community, though he seems much less worried about it. Unlike Wulf, Gibbs seems to accept the science/engineering metaphor. He chides computer scientists for their failure to understand or appreciate the circumstances of practical software development. Nowhere does Gibbs advocate the split mentioned in the title of his paper, although he does accuse the computer science establishment of trying to suppress software engineering just as the mathematics establishment once tried to suppress computer science. The implication that the current conflict may lead to the same sort of result is inescapable. Not everyone writing on this topic exhibits such concern about tiffs within the academic family. The 1st quarter 1991 "SERC Newsletter" carried a piece with the title "Computer Science vs. Software Engineering" by Richard A. Zahniser of CASELab, Inc., of Colorado Springs ["SERC Newsletter," v. 5, n. 1, pp. 1, 3, 1st qtr. 1991]. (SERC is the Software Engineering Research Center.) Zahniser, like Gibbs, freely uses the science/engineering metaphor, but he seems to take for granted that education in software engineering should be quite different from that in computer science. "Their goals [those of computer science and software engineering] are different," he says, "and their training should be different to meet those goals." Zahniser proposes a test to separate computer science work from software engineering work. If failure is acceptable because it leads to new knowledge, you are doing computer science; if failure is unacceptable, you are doing software engineering. He ends by saying If you currently have a computer science degree, it may be hard for you to agree with me. However, ask yourself... [sic] what are you doing (for pay)? How acceptable is failure? Is failure serendipitous, or can you lose your job if you don't deliver a product. [sic] If failure is a stigma in your job, then you're probably a software engineer, regardless of your title or degree. It is probably too early to predict if the split within academic computer science will occur, but the more abstract split in focus seems inevitable and, in 1992, perhaps historic. I do not think that computer science in the exact form we see it now should be preserved, and in that both Wulf and Gibbs seem to agree with me. Software engineering education is needed now, and whether that requires a split from computer science seems an issue more in the hands of computer science professors than in the hands of educators committed to software engineering. 2================================2================================2 Subject: Teaching Testing From: Brian Marick As a submission, here's the results of a survey I took last year: To: testing-archive@ernie.cs.uiuc.edu Subject: Teaching testing I wrote: From: marick@cs.uiuc.edu (Brian Marick) As far as I can tell, most universities teach testing at the tail end of the software engineering course (and, like in development, testing often gets short-changed when time runs out). I'd like to compile a list of universities that specialize a bit more in testing. If you are at such a university, would you drop me a brief note describing your program -- what specialized courses you have, whether there are independent studies projects that require testing, co-op work, research projects that involve undergraduates and graduates, faculty involved, the emphasis of your program, and so on? I will collate the responses and publish them in Testing-Archive. I hope that industrial readers will find it useful -- back when I did a lot of interviewing, we were always looking for people who knew how to test. Brian Marick Motorola @ University of Illinois Email: marick@cs.uiuc.edu, uiucdcs!marick ----------------------- I received these replies: From: weisss@SPUNKY.CS.NYU.EDU (Stewart Weiss) I have been teaching a course in software testing and verification to senior level undergraduates at Hunter College. I have taught it twice in the last two and a half years, and I will probably continue to teach it every third semester. Half of the course is on testing, mostly unit testing, and half on Floyd's verification method. Hunter also pays lip service to testing in its software engineering course for undergraduates, but not much more than that. I am almost finished with a MacIntosh based software testing tool modelled after ASSET which I will use for instruction and experiments related to student software testing activities. Stewart Weiss Computer Science Dep't. Hunter College 695 Park Avenue New York, NY 10021 From: weyuker@GROUCHO.CS.NYU.EDU (Elaine Weyuker) We certainly don't have anything vaguely like a "program", and in fact I'm going to teach an undergrad software eng course for the first time next semester. I taught a grad version once last year, and will also be doing that this spring. However, I have taught a grad course in testing 3 time I think (I just finished it this semester). It tends to attract part-time Master's students, many of whom are working. It is lecture style (as opposed to a seminar). I talk about lots of different types of testing, surveying the literature. I don't use a book. The studewnts are required to write a term paper. Elaine From: ofut@hubcap.clemson.edu (A. Jeff Offutt) > As far as I can tell, most universities teach testing at the tail end I've managed to infuse a little bit of testing at all levels: Data Structures (CS IV): I developed a set of lab exercises for this course, one of which emphasized testing. We gave them a program that was seeded with 10 or so faults, and asked them to detect and fix each fault. By "detect", they had to submit a test case that caused each fault to result in a failure. Software Engineering (Senior): The classic lifecycle course (we used Sommerville). I'm less likely to shortchange testing in this course than the other folks who teach it. The course includes a project that typically emphasizes the _process_ rather than the _product_, and includes a testing phase. This past semester I had them build parts of a mutation system for their project. They developed requirements, designed, implemented, and tested pieces of the IMSCU system that I've mentioned to you previously. I had them go through unit, subsystem and integration testing. Starting next fall, Clemson will offer two undergrad courses in software engineering; the Junior level course will cover the lifecycle (including testing) with no project, and the Senior course will focus on a complete project and discuss "advanced" topics. I plan to include a significant module on software testing (2 to 3 weeks). The junior course will also include a homework assignment similar to the lab in the data structures class, but more extensive (bigger software, more subtle faults). Software Testing (advanced Graduate): This course is entirely software testing, primarily at the unit and module level. There is no book (obviously), so I select papers from the literature to try to cover the significant testing techniques. I try to look at the current state of practice (what's used), art (available but not _yet_ used), and research (not yet proven to be useful). In past semesters, we've done projects. Last spring, I gave them a parser and an interpreter and had two-person teams implement a mutation system (yes, IMSCU) by adding a mutant maker, a decompiler, a statistics analyzer, and the code for the interpreter to execute mutations. I tried to model the project after classic compiler project, and gave them most of the design, or at least design options for each step. From: Stu Zweben Brian, at Ohio State University, I teach a graduate seminar in the area of testing. In it, we study some of the theory of testing (a la Howden) and some of the undecidability results that characterize the area of testing. We also study several of the more popular code-based testing methods such as the families of control flow and data flow coverage, and mutation testing. We also study approaches to testing based on specifications, and those based on defects. Students in the seminar are expected to research some area within testing and make a presentation on it to the class. This normally involves reading a couple of papers that I suggest, and anything else that they may discover in their tracking down of some references from these papers. Finally, we normally do some kind of empirical study in the seminar. It is typically a study of some aspect of the manner in which students test their programs (using OSU students) or a study of defects that exist in such programs (or a combination of the two). The intent is to give the students some experience in doing empirical studies of programmers, and also to see what testing strategies are capable of finding defects that are actually observed in programs. There is also the opportunity to do individual studies work in the area of testing, which could result in a more comprehensive investigation of some aspect of testing than is possible in the seminar; this is particularly so in the empirical studies area. Stu [Later:] In my previous message, I only mentioned courses that were SPECIALIZED to testing. We certainly have other courses in which testing is a component. For example, there is a senior/first-year-grad level software engineering principles course (a la Sommerville or Pressman) in which testing is one of several topics. There is also a junior level course in systems that I teach in which group projects are required. Among other things, test plans are required to be developed and executed, though the subject of systematic testing methods is not covered in this course (i.e., we're emphasizing PROCESS rather than METHOD). In the software engineering course, especially when taught by Gary Perlman, tools are a big item, and students are given the opportunity to use apply simple coverage techniques using basic unix tools. Stu From: hamlet@cs.pdx.edu Portland State University has a software-engineering track in its MS program, with two core courses. The first covers roughly specification and high-level design, the second covers design/implementation and testing. In the latter course, testing gets most of the time, because students already know a good deal about implementation issues. We have just started the Laboratory for Software Quality Research (LSQR) at Portland State. It is an industrial-affiliates program in which testing (along with metrics and human-computer-interface research) is one of the main research areas. There is both foundational work on probabalistic testing theory, and more practical efforts on methods and tools. We actively seek industrial partners with testing projects and testing needs. (For example, Mentor Graphics has recently becom a C++ shop, and has both interest and data on O-O testing.) Graduate assistantships are available both in support of grant-funded research, in LSQR, and through the Department; any of these could involve testing projects. For information, contact Dick Hamlet (hamlet@cs.pdx.edu, 503-725-3216). From: shimeall@taurus.cs.nps.navy.mil (timothy shimeall) At NPS: I (in the Computer Science Dept.) and Norm Schneidewind (in the Admin. Sci Dept.) both have active research interests in testing (although we have not joined up on any projects, thus far). We have a software engineering project course with a testing component, similar to what you describe. I teach a special-topics course in software testing. Tim Shimeall Naval Postgraduate School >From marick Tue Jan 15 08:11:14 1991 Received: by ernie.cs.uiuc.edu.cs.uiuc.edu (4.0/NCSA-1.2) id AA21052; Tue, 15 Jan 91 08:11:14 CST Date: Tue, 15 Jan 91 08:11:14 CST From: marick (Brian Marick) Message-Id: <9101151411.AA21052@ernie.cs.uiuc.edu.cs.uiuc.edu> To: testing-archive@ernie.cs.uiuc.edu Subject: [apm@cs.purdue.edu: Re: Teaching testing] > From: apm@cs.purdue.edu (Aditya P. Mathur) 1. I teach software testing for about 4 weeks at the BEGINNING of our graduate course in software engineering (CS 510). 2. Subgroups of students carry out different projects (mostly, but not all) in testing. 3. Students use Mothra (mutation), ASSET (data flow, courtesy Elaine W). 4. Research papers on mutation, data flow and other testing strategies are used. No textbook..though DeMillo' etal's book on Testing is used as a reference. 5. Projects are of "researchy" in nature. For example, in Fall 90 a group of about 20 students spent many hours comparing the relative strenghts of data flow and mutation. I have over 100 pages of reprots that I plan to condense into a paper. Aditya 3================================3================================3 Subject: Resources For Teaching Testing From: Brian Marick If you're teaching testing in a software engineering class, you may find the following useful: 1. A branch coverage tool for C. I use this tool (and a not-yet-available successor) to show how coverage is used to test the test suite. 2. Homework assignments for unit testing: informal specifications, programs, test drivers, and solutions. The units are extracted from GNU Make, RCS, and Ghostscript, so they present realistic challenges. Both of these are available from cs.uiuc.edu:/pub/testing by anonymous FTP. See spr91.README in that directory for more information about the homework. The following note describes the branch coverage tool. Brian Marick. ------------ This note announces the public availability of version 1.3 of a tool for measuring the branch coverage of C programs. The tool was written by Thomas Hoch, K. Wolfram Schafer (University of Illinois), and Brian Marick (Motorola). The tool is suitable for use in production environments. However, it is unsupported and comes with no warranty. A mailing list is available for mutual support (see below); I will read it and I may fix bugs or documentation in my spare time. If you are a Motorola employee, I will provide full support. Motorola pays my salary. Description This tool is used to measure whether a test suite forces every branch in a program to be taken in every possible way. If it hasn't, you may need to write more tests. The tool is intended to be used in the testing of large systems written in C, including the UNIX kernel and embedded systems. Such systems have certain characteristics that affected the design: 1. The process of compiling the system is a complex task in its own right. The tool should require only minor and isolated changes to this process. (If you use makefiles, usually only one needs to be changed.) 2. Such systems often must be cross-compiled on a host and then downloaded to the target machine, or they depend on a particular C compiler in some other way. Therefore, adding branch coverage instrumentation must be a source-to-source transformation. 3. Embedded systems will not be able to use ordinary file I/O. The internal interface is designed and documented so that the tester can easily write the code used to extract branch coverage information. (When testing application programs, you just use the code provided with the tool.) Example Suppose you have this program: main(argc) { if (argc % 2 == 0) printf("argc is even.\n"); while (argc--) printf("argc %d\n", argc); btool_writelog("LOG");/* Must be added to use the tool. */ } When you instrument it, you get this program: main(argc) { if(btool_branch(0, (argc % 2 == 0)!=0)) printf("argc is even.\n"); while(btool_branch(1, (argc--)!=0)) printf("argc %d\n", argc); btool_writelog("LOG"); } After compiling, you would execute the program once to get: % a.out argc 0 % mv LOG LOG.1 % breport LOG.1 "test.c", line 3: if was taken TRUE 0, FALSE 1 times. "test.c", line 5: while was taken TRUE 1, FALSE 1 times. And again, to get: % a.out 1 2 3 4 5 argc is even. argc 5 argc 4 argc 3 argc 2 argc 1 argc 0 % mv LOG LOG.2 % breport LOG.2 "test.c", line 3: if was taken TRUE 1, FALSE 0 times. "test.c", line 5: while was taken TRUE 6, FALSE 1 times. You can check the branch coverage with % bmerge LOG.1 LOG.2 | breport | bsummary Branches taken in true and false direction 2 (100.00%) Branches taken only in true direction 0 ( 0.00%) Branches taken only in false direction 0 ( 0.00%) Branches not taken at all 0 ( 0.00%) Total number of branches 2 Cases taken 0 ( 0.00%) Total number of cases 0 You've reached 100% branch coverage. The tool can also be used for profiling. For example, a UNIX kernel tester discovered a significant performance problem by noticing how many times a while loop had been executed. Deficiencies 1. The tool itself runs only on UNIX, although the instrumented code may be compiled wherever you like. 2. The tool is based on the GNU C compiler and still contains the original code generation and optimization code. This has two practical disadvantages: - The tool is large: 23000 512-byte blocks are needed when compiling the distribution. The binaries take up 4500 blocks. - The original compiler is made portable through machine and system configuration files. These must still be used. The distribution includes configuration files for many different machines. If there isn't one for your machine, you may be able to use one for a similar machine. For example, since both are derived from BSD UNIX, a tool using a VAX configuration file can be compiled and used on a Sun. The tool is known to run on Sun-3, Motorola SysV68, and Motorola 88K machines. Availability 1. Anonymous FTP. Get the tool via anonymous FTP from cs.uiuc.edu. It is in the directory pub/testing/btool.tar.Z and is a compressed tar file. 2. UUCP The tool and documentation is also available from UUNET under ~ftp/pub/branch-tool. UUNET subscribers should fetch the tool as usual. Others can call 1-900-GOT-SRCS or contact UUNET at UUNET Technologies, Inc. 3110 Fairview Park Drive, Suite 570 Falls Church, VA 22042 +1 703 876 5050 (voice) +1 703 876 5059 (fax) info@uunet.uu.net 3. Tape To get a tape and user's manual, send $100 check or money order (no purchase orders) to Rhonda Murphy, 3270 DCL Department of Computer Science University of Illinois 1304 West Springfield Avenue Urbana, Illinois 61801 The check should be made out to the University of Illinois. ---------------------------- For more information: Brian Marick, Motorola, 1101 E. University, Urbana, Ill. 61801. Ph: (217) 384-8500 or (217) 351-7228. marick@cs.uiuc.edu or uiucdcs!marick Mailing List Btool@cs.uiuc.edu is a mailing list for btool users. It will be used to distribute bug reports, bug fixes, troubleshooting hints, documentation errata, and anything else of interest to btool users. Mail to Btool-Request@cs.uiuc.edu will get you added to the list. 4================================4================================4 Subject: EXPANDING THE PIPELINE From: lwerth@cs.utexas.edu (Laurie Werth) The CRA's (Computing Research Association) Committee on the Status of Women in Computer Science, chaired by Maria Klawe and Nancy Leveson, held its first meeting June 14 at the University of California, Irvine campus. Initial projects and project coordinators include: Databases and Lists Joan Feigenbaum, jf@research.att.com Collect and disseminate names and other information about women researchers and graduate students in computer science and computer engineering. Monitor level of participation of women in professional activities with computer science research such editorial boards, program committees, etc. Women's Speaker's List Marilyn Livingson, lvngstn@eecs.umich.edu Women speakers from the database and topics about which they are willing to give talks. Surveys Nancy Leveson, nancy@ics.usi.edu Collect information on problems in order to better plan activities. CRN Articles Fran Berman, berman@cs.ucsd.edu Columns in the CRN will also be compile as technical reports. Various lists will also be available electronically. Enhanced Communication Michael Fischer, fisher-michael@cs.yale.edu Ideas include a newsletter, possibly electronic, and a moderated mailing list of information and opinions not offered by the systers network. Mentoring Activities Maria Klawe, klawe@cs.ubc.ca Encompasses programs at all levels, from K-12, undergraduate and graduate education and faculty. Their goal is provide information about successful programs and possible start new programs. Career Booklet Thelma Estrin, estrin@cs.ucla.edu Describe careers in computer science and highlight successful women in the discipline. Student Awards Jill Mesirov, mesirov@think.com Create awards analogous to the Women in Mathematics, at the undergraduate and graduate levels. Regional Workshops Nancy Leveson, nancy@ics.usi.edu Provide information on how to hold a regional workshop and on previous successful ones. Programs may be research oriented or informational. Target Workshops Maria Klawe, klawe@cs.ubc.ca Bring together top male and female third-year computer science undergraduates from 20-25 departments for a weekend in May or June to encourage the students to attend graduate school. To subscribe, contact : Computer Research News (CRN) Subscription Department Computing Research Association 1625 Massachusetts Ave, NW, Suite 10 Washington, DC 20036-2212 or email: kimberly@cs.umd.edu Free subscription are available to (1) faculty members, administrators and full-time researchers of college and university computing departments, (2) research staff members and administrators of nonprofit and for-profit laboratories involved in computing research and (3) person who affect policies related to computing research. Laurie 5================================5================================5 Suject: SOFTWARE ENGINEERING EDUCATION AT SIGCSE TECHNICAL SYMPOSIUM From: Lionel Deimel The Advance Program for the 1992 SIGCSE Technical Symposium in Kansas City lists at least two presentations that should be of special interest to FASE subscribers. On Thursday, March 5, from 10:30 am to noon, is a panel session, "Software Engineering and Undergraduate Computing Curricula," organized by Stu Zweben of Ohio State University. The other panelists are not mentioned in the advance program, but Stu provides the following information: The other panelists are Bruce Barnes, who will compare aspects of the SEI undergraduate curriculum in software engineering and the ACM/IEEE-CS task force's curriculum recommendations; Dennis Frailey of Texas Instruments, who will address things like what industry needs in the way of software engineering education from the undergraduates it is hiring; and Linda Northrop, currently at the U.S. Air Force Academy, who will discuss issues of teaching software engineering to undergraduates. At 2:30 pm that same day, in paper session "Concurrency/Software Engineering I," a paper by James Kiper of Miami University and by Michael J. Lutz and Henry A. Etlinger of Rochester Institute of Technology will be presented. The title of that paper is "Undergraduate Software Engineering Laboratories: A Progress Report from Two Universities." Mark your calendars. 6================================6================================6 Subject: FASE Mailing List From: Jochen Ludewig I appreciate the idea of a forum for communication about SE at academia. I had a similar idea last year, and I have organized a workshop (in German) on the same topic. It's named SEUH (Software Engineering in education at universities and colleges), and it is scheduled for February 27/28, 1992, at our site at Stuttgart. Unlike the series of SEE conferences in the US, SEUH is the first event of its kind in Germany, and we hope to see representatives from almost all relevant universities (i.e. those doing some SE). In general, we in Germany are far from a common understanding what SE means, and how it should be tought. If you wish, I will mail a summary after the meeting. I do hope that FASE will be successful, and becomes a truly international activity, not a US club that accepts some non US members. Jochen Ludewig 7================================7================================7 Subject: Undergraduate Computer Science Curriculum, Multi-term, Multi-class projects, etc. From: Mike Overstreet At Old Dominion University, we are just beginning to discuss a redesign of the undergradate computer science curriculum with the idea of adding a significant software engineering emphasis. Some interest exists here in including in the redesign the use of a project which will span multiple terms and for which different classes will have responsibilities for different aspects and different stages in the lifecycle of the project. My request is this: does someone have experience with multi-term, multi-class projects which he/she is willing to share? Successes, failures, lessons learned would all be of interest. I am concerned about the logistics of such an approach and would like to hear about the experiences of others who have attempted something similar. I hate to repeat other people's mistakes when there are so many new ones waiting to be made. All discussion on this would be of interest. Related to this is another question: if you were to design an undergraduate software engineering curriculum, say of 45 semester hours, what course would you include from an existing `traditional' CS undergraduate curriuculum? What new courses, usually not offered in a CS curriculum, should be included? Mike Overstreet Computer Science Department Old Dominion University Norfolk, VA cmo@cs.odu.edu 8================================8================================8 Subject: The IEEE CS First Annual National Programming Contest From: lwerth@cs.utexas.edu (Laurie Werth) The IEEE CS National Programming Contest (NPC) is a new form of computer programming contest geared towards undergraduate students. The NPC is based on the Statewide Programming Contest, which the University of Texas at Austin IEEE CS has held 9 times (semi-annually) with great success. The contest consisted of 16 teams with three contestants per team: Alma College, Berkeley, Caltech, Central Florida, Cornell, Kansas State, MIT, Oberlin, University of. Pennsylvania, Rice, Stanford, Texas, Toronto, Trinity, UCLA, and Wisconsin. Contestants create players fora game called "Gobble". It was basically a capture-the-flag game. The object was to get one of your players to the middle of the screen, pick up the turkey, and return it to your side. On each team were three players, Ma, Pa, and Squirt. Ma was very strong and was armed with a frying pan which could be swung very quickly but had a short range, and she moved slowly. Pa was almost as strong as Ma, but he was armed with a hoe which has a slightly longer reach but less power than a frying pan; he was slightly faster than Ma. Squirt is the weakest but fastest player, armed with a slingshot which takes a long time to shoot but has an infinite range. If a player is hit enough times (depending on his strength), he or she will pass out temporarily and recuperate his/her strength. There is no way to kill another player permanently, and the turkey could not be killed. Furthermore, the person carrying the turkey cannot shoot and moves at half speed. Once the contestants have written their players, the contest proceeds as a double elimination playoff among the teams. Contestants wrote programs to control their players for them. Whereas humans are very good at playing strategic games and seeing the overall view, computers are very good at reflexes. The challenge was to approach a human's ability to play a game. In addition, it was a six player game; that is, the three players on a side (team) must cooperate with each other. The contest administrators wrote the game controller with the help of several students from the Department of Computer Sciences and several graphic artists from the Art Department. Both the statewide and national contests are organized completely by students. This year's NPC was held at the University of Texas at Austin in the Alumni Center on November 30, 1991. Activities included a banquet with a program by Dr. Andrew Koenig of AT&T, entitled "The Art of the Hack" The double elimination playoff was completed on December 14, 1991. The 1991 NPC Winner is Rice University. Second place was MIT. Prizes were provided by Microsoft, Hewlett-Packard and Origin. The financing for this year's contest, $11,500.00 to date, came from the following sponsors: IEEE Central Texas Section, IEEE CS Technical Committee on Software Engineering (TCSE), Motorola, Southwestern Bell, College of Engineering and Electrical Engineering Department at the University of Texas at Austin. Hardware loaned by vendors for the contest included: Sun Microsystems: 16 Sparcstation 2's, 1 Sparcstation IPX. NCD: 32 X terminals, St. Claire Systems: transceivers and cabling. Technical Educational Services: Chromalux RGB projector Any NPC '91 contest questions should be directed to: Jeff Schaver: jschaver@ccwf.cc.utexas.edu, or Ashish Parikh: ashish@ccwf.cc.utexas.edu Any technical/NPC '92 questions should be directed to: David Taylor: ddt@ccwf.cc.utexas.edu To send mail to a discussion group on next year's game, send e-mail to: npc@austin.eds.com. To get on the distribution list, write: mayoff@ccwf.cc.utexas.edu. The IEEE CS office number is (512) 471-5038. 9================================9================================9 Subject: Drexel Position Announcement From: jpopyack@mcs.drexel.edu (Jeffrey Popyack) The Department of Mathematics and Computer Science at Drexel University is recruiting for two approved tenure track vacancies. Due to recent retirements, we anticipate approval of an additional position. We are interested primarily in candidates with the background described below; however, we are also particularly interested in recruiting female and minority candidates. I would greatly appreciate it if you would bring the following announcement to the attention of current or recent Ph.D. candidates. _______________________________________________________________ James C. T. Pool, Head Telephone: 215-895-2668 Mathematics and Computer Science FAX: 215-895-4999 206 Korman Center DREXEL UNIVERSITY Email: jpool@mcs.drexel.edu Philadelphia, PA 19104-2884 ________________________________________________________________ POSITION ANNOUNCEMENT DREXEL UNIVERSITY The Department of Mathematics and Computer Science is seeking computer scientists and applied mathematicians for tenure-track and visiting appointments - assistant professor through professor - for Academic Year 1992-93. Research activities in one of the following areas is essential with priority given to the first three areas: parallel and distributed computing: languages, compilers, tools, and _software engineering_ for parallel and distributed computing environments. computer algebra: algorithms for scalable parallel systems; design of software, systems and user environments; integration of symbolic, numeric and graphic tools including generation of numerical software; applications in computational science and engineering. computer graphics and human computer interfaces: visualiza- tion; graphical user interfaces; knowledge-based advisory/help systems; applications in computational science and engineer- ing. mathematics and computer science education: role of the com- puter - personal computer to supercomputer - in the undergra- duate curriculum; curriculum revision; design of instructional methods, software and systems. Send a letter stating research interests, a resume, and the names of three or more references to: James C. T. Pool, Head Mathematics and Computer Science 206 Korman Center Drexel University Philadelphia, PA 19104-2884 INTERNET: jpool@mcs.drexel.edu Application deadline is January 31, 1992 or until approved positions are filled. Drexel University is an Equal Opportunity/Affirmative Action Employer. 10===============================10===============================10 Subject: A New Textbook From Aksen Associates/Irwin Publishing Company From: Howard Aksen I'd like to submit the following information about our newest textbook, Practical Software Engineering, by Stephen R. Schach of Vanderbilt University. The book will be published February 14, 1992. I believe it will be of interest to many of your readers. I'll appreciate your posting this information in the newsletter. Practical Software Engineering Stephen R. Schach, Vanderbilt University Introduces the future software professional to the practical aspects of software engineering used in industry. Assumes only a previous course in programming and some knowledge of C. Emphasizes programming in teams (a case study, including dialogue among team members, provides continuity throughout the text). Stresses the importance of maintenance; the use of correct and complete documentation; the need for testing throughout the software life cycle to boost software quality; and the importance of CASE (computer-aided software engineering) tools to increase software productivity. Chapter 1 Introduction To Software Engineering Chapter 2 Life-Cycle Models Chapter 3 Requirements Phase Chapter 4 Specification Phase Chapter 5 Planning Phase Chapter 6 Design Phase 1: Object-Oriented Design Chapter 7 Design Phase 2: Detailed Design Chapter 8 Design Phase 3: Information Hiding Aspects Chapter 9 Implementation Overview Chapter 10 Implementation and Integration Phase Chapter 11 Maintenance Phase Postscript Bibliography Appendix A Chocoholics Anonymous Appendix B First Version of Rapid Prototype Appendix C Specification Document for C-CC Product Appendix D Source Code For C-CC Product Appendix E Makefile for C-CC Product Index 1992/ISBN 0-256-11214-2 /Book no. 19-3767-01 324 pp Hardbound Tent. price $39.95 U.S. Instructor's Solutions Manual free to adopters Published by: Richard D. Irwin, Inc. and Aksen Associates, Inc. 1818 Ridge Road Homewood, IL 60430 To order and exmination copy please call faculty service at 1-800-323-4560 (U.S. only) To purchase a copy please call customer service at 1-800-634-3961 (U.S. only) If you are outside the continental U.S. please call 708-957-5800 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)749-3144, 749-4791 % % Fax: (713)749-2378 % % Email: pnlee@cs.uh.edu % % Email: fase@cs.uh.edu % % % % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%