Forum for Advancing Software engineering Education Volume 6 Number 14 June 28, 1996 Contents: Undergraduate Software Engineering Degree at RIT ASWEC '96 Call For Registration And Program Distance Learning Models (long) ---------------------------------------------------------------------- From: Michael J Lutz Subject: Undergraduate Software Engineering Degree at RIT RIT OFFERS NATION'S FIRST UNDERGRADUATE DEGREE IN SOFTWARE ENGINEERING Beginning this fall, Rochester Institute of Technology will be the first U.S. university to offer a bachelor of science degree in software engineering. The program was created in response to industry demand, as companies require more reliable and cost effective software. Software engineering involves a teamwork approach to developing, maintaining and enhancing complex, critical software systems. With an emphasis on team-oriented approaches to software development, RIT's software engineering program will prepare students for technical and management careers in a variety of computer and software-intensive industries. Co-sponsored by the departments of computer science and computer engineering, the degree draws on the curricula and expertise of several computer-related disciplines. "As more companies rely on software to meet ever-changing business needs, the demand for software engineers exceeds the number of qualified graduates," says Mike Lutz, professor of computer science. "Through this innovative program, developed with considerable input from leading software-related companies, RIT will be at the forefront in providing industry with software engineering professionals." Students majoring in the program will take 12 new software engineering courses, along with computer science, engineering and arts and humanities courses. The curriculum is designed to meet the accreditation guidelines of the Accreditation Board of Engineering and Technology. "This program will help RIT meet critical needs of its industry partners for engineering talent," says Paul Petersen, dean of the College of Engineering. "Software development has become critical to product development in many industries and should be considered in the same manner as other engineered systems." To find out more about RIT's undergraduate program in software engineering, contact Lutz at (716)475-2472 or e-mail to mjl@cs.rit.edu. ---------------------------------------------------------------------- From: kreed@latcs1.cs.latrobe.edu.au (Karl Reed) Subject: ASWEC '96 Call For Registration And Program THE NINTH AUSTRALIAN SOFTWARE ENGINEERING CONFERENCE Email: iree_office@eol.ieaust.org.au URL: http://www.sd.monash.edu.au/ASWEC96 July 14 - July 18 World Congress Centre Melbourne, Australia The following is an abbreviated program. For complete program, registration information, and detailed descriptions of the tutorials and keynote speeches, see the above web site, or email the conference secretariat at the address above. Official Sponsors The IREE Society (A Technical Society of The Institution of Engineers, Australia) in collaboration with the Software Engineering Research Consultative Council (SERCC) of the Australian Computer Society (ACS). Sponsorship of the Monash University is gratefully acknowledged. Schedule Of Events Sunday - Tutorials Monday - Tutorials Tuesday - Program, Trade Exhibits, Industry Experience Track Wednesday - Program, Trade Exhibits, Conference Dinner Thursday - Program, Trade Exhibits, Conference Close THE CONFERENCE ASWEC is a national forum for sharing ideas, experience and development in the field of software engineering. The conference addresses all aspects of the discipline, including CASE development methods and tools software management innovation and software experience The conference aims to foster and support the involvement of representatives from industry, government bodies and academic institutions. Invited speakers from internationally recognised organisations will give presentations covering he following fields: "Verifiation, Validation and the Future of Software Engineering" John Staples, University of Queensland, Australia "Industry - University Partnerships: The Wave of the Future?" Nancy R. Mead, Carnegie Mellon University, Pittsburgh, USA "A System for Evaluating the Congruence of Software Process Models" Nazim H. Madhavji, McGill University, Montreal, Canada INDUSTRY EXPERIENCE TRACK ASWEC aims to bring together software engineering researchers, educators and practitioners in software industry, government, defense and academia with a view to discussing what, and how, software development models, processes, frameworks and methods can usefully be managed and supported under diverse quality, productivity, time-to-market and capability constraints. ASWEC 96 introduces a track dedicated to the presentation of late-breaking industry experience and case studies of * the application of software engineering methods, techniques and productivity tools, * the management of software-intensive systems on stable, flexible software architecures with interfaces to commercial standards, * integrated software product development capabilities, * disciplined mature software processes and their acquistion in practice, * successes and pitfalls in software development projects. TUTORIAL SESSIONS Tutorial sessions will be held on Sunday, July 14 and Monday, July 15 for conference attendees who wish to be brought up to date with recent advances in several technically and commercially important areas of Software Engineering theory and practice. The tutorial presenters are all experts in their particular areas and have had considerable practical experience of software development. TRADE EXHIBITION AND SPONSORSHIP A Trade Exhibition will be held in conjunction with the Conference. Additional opportunities exist for sponsorship of the Conference activities. For further information contact the ASWEC 96 Conference Secretariat. ASWEC 96 Conference Secretariat Level 1, 118 Alfred Street (PO Box 495) Milsons Point NSW 2061 AUSTRALIA Phone: +61-2-9929-0099 Fax: +61-2-9929-0587 Email: iree_office@eol.ieaust.org.au URL: http://www.sd.monash.edu.au/ASWEC96 ---------------------------------------------------------------------- From: Kathy Beckman Subject: Distance Learning Models DISTANCE LEARNING MODELS Kara Nance University of Alaska Fairbanks ffkln@aurora.alaska.edu Pete Knoke University of Alaska Fairbanks ffpjk@aurora.alaska.edu INTRODUCTION ------------ This paper is a working document. It has the modest goal of reporting some distance education results, experiences and lessons learned that might be helpful to professors who may be considering distance delivery of Software Engineering (SE) courses in the future, but who had not yet had any direct experiences in this area. It has been prepared to satisfy an action from the SE Education Working Group meeting held at Daytona Beach recently. The paper is mostly about three SE courses taught recently at the University of Alaska Fairbanks (UAF) via videoconferencing ([KN96],[NA96], and [KN95]). However, since one author had some prior experience with distance delivery of a computer literacy course to the Alaska bush via Interactive Digital Graphics [KN93A&B], the lessons learned and recommendations cover experiences with both delivery systems. BACKGROUND ---------- UAF has been actively involved with distance education for many years. However, the experiences with the use of videoconferencing systems for distance education are more recent, and relate mostly to SE education. The origins of those efforts are noted briefly below. In late 1993, UAF established a SE track for its existing MS Computer Science program. This track now has 3 graduates, 3 almost-graduates and about a dozen students in various other stages of the pipeline. Several of these other students and a number of new candidates for the program reside in Anchorage, a relatively large Alaska city located 350 miles south of Fairbanks. The Anchorage students are typically employed in Anchorage as software professionals. They seek a Master's degree in SE, but their local University of Alaska Anchorage (UAA) doesn't offer it, and for most of them a move to Fairbanks isn't feasible. To serve such students Computer Science faculty members of UAF and UAA started a cooperative MS Computer Science program in early 1994. The term "virtual department" was used at the time to describe this joint venture. Under this program Anchorage students could pursue the UAF MS CS/ SE degree while remaining resident in Anchorage. Although they can take some required or elective courses for this degree program locally from UAA, certain key courses are available only in Fairbanks. The challenge is to make these courses accessible to the Anchorage students. The University of Alaska (UA) system, with headquarters in Fairbanks, set up a statewide videoconferencing system about 1994 to serve administrative needs. UA administrators made this system available to UAF faculty for distance education purposes on a noninterference basis. However, each course using this system was required to pay communications costs currently set at $50/hr per site. This means that the hourly cost of a Fairbanks-Anchorage videoconference is $100/hr. The actual video conferencing system used is of the "large group" type, called the VTEL 235M by its manufacturer. It consists of about $70k worth of hardware located at each site, plus a central bridging subsystem. Each site has a codec-enhanced PC-based system using compressed video. It uses a bandwidth of 384k bits per second, which leads to adequate but slightly jerky video.. Its attached peripherals include two 35 inch color monitors, several microphones, an ELMO document camera, a Pen Pal Graphics Tablet, a keyboard, and a VCR unit. THREE SOFTWARE ENGINEERING COURSES VIA VIDEOCONFERENCING -------------------------------------------------------- To meet the needs of Anchorage-based students in the UAA-UAF MS CS/SE program, UAF has offered three full-semester SE courses by videoconference over the last 18 months. These courses, their offering semesters and their instructors were: CS694, Software Process Improvement, Spring 1995 (Knoke, instructor) CS670, Computer Science for Software Engineers, Fall 1995 (Nance, coordinator. 6 instructors) CS693, Reengineering/Reusability, Spring 1996 (Nance, instructor) All three courses were offered one night a week from 6:00-9:00 PM for 14 weeks in their respective semesters. They are discussed briefly below, according to the following template: Course Number Course Name Offering Date Distance Learning Model Distance delivery technology (e.g., video and audio conferencing, etc.) Number of instructors (e.g., 1,2, ...,6) Instructor location (e.g., Anchorage, Fairbanks, both, variable, etc.) Number of sites (e.g., 2, 3 ) Character of student bodies at sites (e.g., homogeneous, heterogeneous) Nature of instruction (e.g., interactive, lecture) Communications bandwidth (e.g., high, medium, low) Course Description Discussion Results The Distance Learning Model subtemplate could be expanded and /or modified, perhaps drawing from analogies with existing taxonomies of distributed systems architectures. What is given here is intended only as a starting point, not a polished end result. A LIKELY QUESTION ----------------- Before discussing each of the three courses separately, we address one specific likely question which is applicable to all three, namely: HOW DO THE DISTANCE DELIVERED (VIDEOCONFERENCING) COURSES DIFFER IN CONTENT FROM A THREE-HOUR, ONE-NIGHT PER WEEK COURSES WHERE EVERYONE IS AT THE SAME SITE? The short answer (opinion) to this is: FOR MOST COURSES IN THE SOFTWARE ENGINEERING DOMAIN, NO CHANGES IN CONTENT ARE REQUIRED BECAUSE DISTANCE DELIVERY IS USED. This answer assumes that in the SE course domain all relevant information to, from and between students is received or transmitted by sight or sound (and none by touch, taste or smell). Given a sufficiently high communications bandwidth (the 384k bits per second used by the videoconferencing system is judged to be sufficiently high), no essential course content need be eliminated. (This might not be the case in other course domains, such as cooking, chemistry, or flight instruction). Within the SE domain some tasks such as requirements derivation at a distance can be difficult. Any SE course requiring such derivations, e.g. for real software development projects, would also be difficult to conduct at a distance. Sometimes instructional tasks that are almost trivial to do locally can be done only with great difficulty at a distance. One of the authors once taught the hands-on use of a computer simultaneously to computer novices at three different remote sites in the Alaska bush [KN93A]. Most of the students had no computer experience, and at the remote sites there was no local person to whom the students could turn for help. In this case a physical presence would have made the teaching task easy (See? You hit this key here, and look what happens), but the lack of such a physical presence made it quite difficult. A similar situation might arise when teaching an SE course featuring the use of CASE tools. Course content aside, in the SE course domain as in any other course domain the fact of distance delivery makes significant changes in course teaching and course management style highly desirable or essential. These changes are discussed later in different parts of the paper. COMMON ELEMENTS FOR THE THREE VIDEOCONFERENCING COURSES ------------------------------------------------------- ALL THE COURSES WERE NEW. The courses were freshly developed, with no prior offerings. ALL THE COURSES HAD ONLY TWO SITES The two sites were Fairbanks and Anchorage. The use of a third site (Juneau) is being considered for the future. ALL THE COURSES HAD SIMILAR HETEROGENEOUS STUDENT POPULATIONS The students at Fairbanks were typical MS CS students, while the students at Anchorage were mostly experienced (and employed) software practitioners. ALL THE COURSES INSTRUCTORS WERE INEXPERIENCED WITH VIDEOCONFERENCING And success was possible anyway. This suggests that a videoconferencing distance delivery system can be quite easy to use. ALL THE COURSES WERE QUITE SUCCESSFUL EDUCATIONALLY As judged from student opinions of instruction, student examination results, student project reports and student presentations. . BRIEF INDIVIDUAL REPORTS ON THREE DISTANCE DELIVERED COURSES ------------------------------------------------------------ COURSE NUMBER: CS694 COURSE NAME: Software Process Improvement OFFERING DATE: Spring 1995 DISTANCE LEARNING MODEL: DISTANCE DELIVERY TECHNOLOGY: video conferencing NUMBER OF INSTRUCTORS: 1 INSTRUCTOR LOCATION: Fairbanks NUMBER OF SITES: 2 SITE STUDENT BODY CHARACTER: heterogeneous TEACHING STYLE: interactive COMMUNICATIONS BANDWIDTH: high COURSE DESCRIPTION: Commonly applied methods for improving the software development process. Emphasis on the Software Engineering Institute's Capability Maturity Model (CMM), and specifically on the key process areas of Level 2 and Level 3 of that model. These include software configuration management, software quality assurance, and software standards. DISCUSSION: Covered SPI more broadly than is indicated in the description. Included critiques of the CMM, and alternative process models (ISO 9000, Capers Jones' ideas, etc.). Used lots of current literature, thereby generating additional instructor workload and Federal Express bills for the delivery of handouts. The presence of a UAA instructor at Anchorage helped a lot. He coordinated Anchorage discussions (the Anchorage students tended to be experienced software practitioners who were eager to speak up), helped with handouts, helped with exams and gave an occasional lecture. The fact that the Anchorage students were mostly experienced and vocal software engineers while the Fairbanks students were mostly conventional Computer Science graduate students made for interesting discussions ([KN96],[KN95]). In other words, there was an interesting group dynamics situation in this class. Group dynamics requires special attention in a course offered via interactive video. It is far more difficult for an instructor to control a discussion when the involved parties are geographically distinct. It is more difficult to "call on" specific students for input, particularly when the students are viewing a viewgraph rather than the instructor. In addition it is difficult to move the cameras from speaker to speaker and also be actively involved in the discussion. RESULTS: Students enjoyed the course and gave it good ratings. Exam and project results indicated that student learning objectives were achieved. This first course was also useful as an issues surfacing device. The issues included the handling of handouts, videos, equipment, grading, costs, and group dynamics. They range on a continuum from "easily solvable within course context" to "requires change in statewide policy"([UA95],[UAF95],[UAA95]). Some issues apply to distance learning courses in general while others are specific to CS694. A few were intensified because this first offering combined a new course with a new delivery mechanism, a bad situation from a risk management point of view. COURSE NUMBER: CS670 COURSE NAME: Computer Science for Software Engineers OFFERING DATE: Fall 1995 DISTANCE LEARNING MODEL: DISTANCE DELIVERY TECHNOLOGY: videoconferencing NUMBER OF INSTRUCTORS: 6 INSTRUCTOR LOCATION(S): Fairbanks and Anchorage NUMBER OF SITES: 2 SITE STUDENT BODY CHARACTER: heterogeneous TEACHING STYLE: interactive COMMUNICATIONS BANDWIDTH: high COURSE DESCRIPTION: An overview and survey of the theoretical underpinnings of computer science. Topics are taken from the areas of algorithms and data structures; computer architecture; computer networks, communications and operating systems, computability and formal languages; languages and compilation DISCUSSION: This course was invented to serve as a Computer Science background gapfiller for students in the UAF MS CS/SE track. It is required of students in that track who do not have a bachelor's degree in computer science. In this specific first offering the course had 6-hour modules on each of the following six subject areas: SUBJECT INSTRUCTOR LOCATION ------------------------------------- ------------------- algorithms and data structures Anchorage and Fairbanks operating systems Anchorage computer architecture Fairbanks computer science theory Fairbanks languages and compilers Fairbanks computer networks Anchorage The instructors who offered the modules were those who normally taught the subject on a full semester basis. The relevant question that arises is "how do you put 6 pounds of stuff into a 1 pound bag"? An obvious answer is, "by compression", and this was used. However, more work is needed on the compression algorithms for the CS670 modules. Many of the issues encountered with CS670 were similar to those encountered in CS694. However, some of the issues in that first course were solved prior to this second course offering. CS670 encountered several new problems because of the multiple-faculty delivery method chosen. RESULTS: Much material was covered, and the students absorbed a significant part of it. However, group dynamics continued to be a major issue. In fact it was more of an issue in this course than in CS694 because of the constant changing of the instructors. Because of that, students were unable to develop an informal protocol to guide their discussions, and faculty members were unable to develop the usual class-faculty relationship which fosters meaningful communication. COURSE NUMBER: CS693 COURSE NAME: Reengineering/Reusability OFFERING DATE: Spring 1996 DISTANCE LEARNING MODEL: DISTANCE DELIVERY TECHNOLOGY: videoconferencing NUMBER OF INSTRUCTORS: 1 INSTRUCTOR LOCATION: Fairbanks NUMBER OF SITES: 2 SITE STUDENT BODY CHARACTER: heterogeneous INSTRUCTION STYLE: interactive COMMUNICATIONS BANDWIDTH: high COURSE DESCRIPTION: An overview of approaches and methods that have been used and/or proposed to solve the problem od software reuse. Emphasis on software architecture taxonomies and the effects of software architecture on software reuse feasibility and methods. Includes team projects for research into selected reuse-related areas. DISCUSSION: Like CS694 and CS670, this was also a graduate course targeting the SE track students. It addressed a very current topic and required much supplemental material. The development of a group dynamics informal protocol was facilitated by the instructor. An early lecture in this course was given by distinguished guest lecturer Will Tracz. The issues were similar to those in CS694 because this course was also taught by only one instructor. There were additional equipment reliability problems which had not been encountered in previous semesters; however the problems were solved early in the semester with no recurrences. RESULTS: Group dynamics improved as the students became a peer group and adjusted to the issues associated with distance delivery. Students gave effective presentations of projects from both sites. The use of Email to distribute supplementary materials worked well. Good student learning resulted as judged by exam results and the quality of student project reports and presentations. LESSONS LEARNED --------------- 1) THE INSTRUCTOR MAY HAVE TO MAKE TEACHING STYLE CHANGES The distance element complicates matters for a teacher who uses immediate feedback from students (e.g., from eye contact, body language, facial expressions, etc.). Also, the pure lecture style is even less effective for distance courses than it is for local courses. For distance courses an interactive style should almost always be used if the distance delivery system permits. 2) THE INSTRUCTOR'S WORKLOAD INCREASE CAN BE SIGNIFICANT Logistics difficulties can be much greater for a distance delivered course than for a local one. A teacher who likes to keep the course fresh by use of current handouts may see these difficulties as increased workload. A new distance delivery instructor will probably encounter initial increased workload because of his inexperience. An instructor attempting distance delivery in a teaching environment where almost all course delivery is traditionally local may encounter increased workload because he may have to carry out many new tasks (e.g. provide student registration assistance, struggle with new policy issues, etc.). Such difficulties could go away after an institutional distance delivery support structure is developed. Some examples of possible troublesome policy questions are: 1. Which institution gets the tuition dollars? 2. At which institution do students enroll for the course? 3. Which institution/faculty member gets course credit for the course? 4. How does a credit taken in Anchorage get counted toward a UAF degree given the transfer credit limit? (Courses taken at different branches are currently counted as transfer credits.) 5. How can the courses become self-supporting (i.e., how do you pay for the communications costs)? 3) THE INSTRUCTOR'S SENSE OF HUMOR IS VERY IMPORTANT Murphy's Law seems to apply more forcefully to distance-delivered courses than to local courses. There may be times when the instructor is faced with problems for which about all he can do in the short term is "grin and bear it". 4) THE INSTRUCTOR NEEDS RISK MANAGEMENT AND CONTINGENCY PLANS Murphy's Law again. A good course risk management plan is needed. In the case of video conferencing, your ability to deliver course content is at the mercy of the integrity of the communications links plus the operability of such equipment as the TV monitors, TV cameras, camera control devices, and the ELMO. What are you going to do when your video picture of the remote class slowly turns from normal to pink to deep red to black during the class? What are you going to do when the audio channel suddenly emits a loud conversation between two ladies with no relationship to the class? Etc. 5). THE INSTRUCTOR NEEDS TO BE FLEXIBLE Murphy's Law again. Real time planning and decision making may be necessary because of unexpected events. 6).HIGH RELIABILITY OF THE DISTANCE DELIVERY SYSTEM IS CRITICAL An instructor without distance delivery experience might be tempted to assume that his distance delivery equipment has high reliability. Alternatively, he might be tempted to adopt a new state-of-the-art and operationally unproven distance delivery equipment for use in a course. In the three videoconferencing courses reported in this paper, the system was mature, operational and under regular maintenance, and still it failed such that significant parts of course sessions had to be canceled occasionally. 7) VIDEOTAPES DON'T WORK WELL WITH COMPRESSED VIDEO, AND THEIR USE OVER THE AIRWAYS IS ILLEGAL. Some videotapes were used in CS694. The first time one was used, it was played on a VCR machine at Fairbanks and transmitted to Anchorage by compressed video. This attempt produced many complaints from Anchorage about poor video quality. After that, all future videotape showings were done with a separate video tape at each site. This was for the best, because later the instructor learned from the UAF Provost that sending a videotape "over the airways" is presently regarded as a violation of videotape copyright laws. 8) FOR LARGE GROUP VIDEOCONFERENCING A CAMERA OPERATOR IS NEEDED AT EACH SITE, AND CAMERA OPERATION PROTOCOLS ARE NEEDED With large group videoconferencing there is a video camera at each site, hence two cameras for two sites. With the equipment used, both cameras can be operated from either site. Thus some camera operation protocols have to be worked out, otherwise the site camera operators will struggle with each other for camera control. In the UAF courses, the cameras were operated (i.e., pointed, zoomed, etc.) by students in the class. 9) DISTANCE DELIVERY CAN LEAD TO SURPRISING EXPERIENCES, BOTH GOOD AND BAD Examples of the good experiences are the heated intersite and intrasite SPI discussions [KN95] and the case of the group Christmas card[KN93A]. An example of a bad experience is the case of Rita and the chimp [KN93A]. RECOMMENDATIONS --------------- 1) CONSIDER THE "LESSONS LEARNED" CITED ABOVE 2) CHECK DISTANCE EDUCATION LITERATURE FOR GENERIC DISTANCE DELIVERY HINTS 3) CHECK WITH PEOPLE WHO ARE EXPERIENCED WITH THE USE OF THE PARTICULAR DISTANCE DELIVERY SYSTEM THAT YOU PROPOSE TO USE 4) CHECK WITH THE MANUFACTURER/VENDOR OF THE DISTANCE DELIVERY SYSTEM THAT YOU PROPOSE TO USE (CF [AT94]. 5) DON'T TRY TO TEACH A COURSE VIA DISTANCE DELIVERY USING A DISTANCE DELIVERY SYSTEM THAT IS NOT MATURE, PROVEN, AND UNDER MAINTENANCE. 6) GET SOME EXPERIENCE WITH THE USE OF YOUR DISTANCE DELIVERY SYSTEM BEFORE YOU FIRST USE IT "LIVE" IN THE COURSE. 7) AVOID COMBINING THE TEACHING A NEW COURSE WITH THE USE OF A DISTANCE DELIVERY SYSTEM WITH WHICH YOU ARE NOT FAMILIAR REFERENCES ---------- [KN96] "A Software Process Improvement Course via Video Conferencing", P.Knoke, EdMedia/Ed-Telecom 96 proceedings, Boston, Mass. 17-22 Jun 96. [NA96] "Collaborative Distance Delivery", K. Nance and P. Knoke, EdMedia/Ed-Telecom 96 proceedings, Boston Mass, 17-22 Jun 96 [KN95] "A Software Process Improvement Course via Videoconferencing". P.Knoke, unpublished UAF Technical Report. [UA95] University of Alaska, Board of Regents Policy [UAA95] University of Alaska, Anchorage policy statements. [UAF95] University of Alaska, Fairbanks policy statements. [AT94] Alaska Telecommunication Network. "Video Conference Training Handbook: End User Training Kit", Alascom, Anchorage, Alaska, Jan 1994. [KN93A] "TeleTeaching with IDG in Interior Alaska", P. Knoke, in Teleteaching: Proceedings of the IFIP TC3 Third Teleteaching Conference, North-Holland, 1993, pp 513-522. [KN93B] "Preliminary Evaluation of IDG Technology for Distance Education in Alaska", P. Knoke, Proceedings of NECC'93, June 27-30, 1993, Orlando, FL. pp 122-129. E------------------------------------------------------------------- FASE Volume 6 Number 13 Send newsletter articles to one of the editors, preferably by category: Articles pertinent to corporate and government training to Kathy Beckman, sdmce@access.digex.net; Academic education, and all other categories to fase@cs-server.d.umn.edu, or to Keith Pierce, kpierce@d.umn.edu. Send requests for information or to add or delete a subscription to fase-request@cs-server.d.umn.edu with one of the words HELP, SUBSCRIBE, or UNSUBSCRIBE in the SUBJECT line. Send problem reports, returned mail, or other correspondence about this newsletter to kpierce@d.umn.edu You can retrieve back issues by anonymous FTP from from ricis.cl.uh.edu or through WWW at URL http://ricis.cl.uh.edu/FASE/ Keith Pierce -- Academic/Misc Editor and ListMaster University of Minnesota Duluth, Duluth, MN 55812-2496 USA Phone: 218- 726-7194 Fax: 218-726-6360 Email: kpierce@d.umn.edu Kathy Beckman -- Corporate/Government Editor Computer Data Systems One Curie Ct., Rockville MD 20850 USA Phone: 301-921-7027 Fax: 301-921-1004 Email: sdmce@access.digex.net David Eichmann -- FASE Archivist University of Houston - Clear Lake Box 113, 2700 Bay Area Blvd., Houston, TX 77058 USA Web: http://ricis.cl.uh.edu/eichmann/ Phone: 713-283-3875 Fax: 713-283-3810 Email: eichmann@rbse.jsc.nasa.gov or eichmann@cl.uh.edu Laurie Werth -- Advisory Committee Taylor Hall 2.124 University of Texas at Austin, Austin, Texas 78712 USA Phone: 512-471-9535 Fax: 512-471-8885 Email: lwerth@cs.utexas.edu Nancy Mead -- Advisory Committee Software Engineering Institute 5000 Forbes Ave. Pittsburgh, PA 15213 USA Phone: 412-268-5756 Fax: 412-268-5758 Email: nrm@sei.cmu.edu