Forum for Advancing Software engineering Education (FASE) Volume 10 Number 01 (120th Issue) - January 15, 2000 895 subscribers Note: If you have problems with the format of this document, try An HTML version of this issue is available at ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Letter From the FASE Archivist: Solving the V10 Bug This Month's Topic: Coping with the Faculty Shortage Last Month's Topic: Addendum Next Month's Topic: Top Ten Contributions - Don't Forget to Vote! Call for Guest Editors and Topic Suggestions News Items IEEE Software Roundtable: Best Influences on SE IEEE Software Letters to the Editor on Professional SE Undergraduate Software Engineering at Butler University Calls for Participation IEEE-CS State-of-the-Practice Survey Conference Announcements CSEE&T 2000 Final Program Position Openings Florida State University University of Nebraska-Lincoln (tenure-track position) University of Nebraska-Lincoln (chair position) Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Don Bagert (FASE Archivist) Letter From the FASE Archivist: Solving the V10 Bug Since I know all of you are tired of hearing about the Y2K bug, here is an interesting little problem concerning the FASE ftp archive, which is at ftp://www.cs.ttu.edu/fase/archive/ Now that FASE is entering its tenth year of publication, in order to get Volume 10 (or V10) after Volumes 1-9 9, the first part of the prefix for all of the single-digit volumes have been changed in the ftp archive to have a leading zero in the volume. So, v1n01.txt became v09n01.txt, and so forth. In that matter, the lexicographic order of the files in the ftp listing is the same as the chronological order. As far the Web archive, accessible from http://www.cs.ttu.edu/fase goes, both old and new filenames will be used. So, either http://www.cs.ttu.edu/fase/v1n01.txt and http://www.cs.ttu.edu/fase/v01n01.txt will access Volume 1, Number 1 of FASE. So...the V10 is problem solved, and for about $250 billion dollars less than the USA spent on Y2K bug! (Of course, the problem is only solved until Volume 100, Number 1 comes out in January 2090, but that will be someone else's problem =) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This Month's Topic: Coping with the Faculty Shortage Topic Editor: Don Bagert, Texas Tech University Don.Bagert@ttu.edu Several distinguished leaders in software engineering were given the following topic description: "As work of the IEEE-CS/ACM Software Engineering Coordinating Committee (SWECC) and its related groups progress, attention is increasingly shifting to implementation. A major roadblock to the implementation of software engineering degree programs is the lack of qualified full-time faculty. This issue will focus on the problem, and suggest solutions." Contributions are enclosed from: James H. Cross II Chair of Computer Science and Engineering Auburn University Peter B. Henderson, Head Department of Computer Science Butler University Joseph Kasser (with two articles!) Adjunct Associate Professor University of South Australia Kenneth L. Modesitt Professor and Chair and Bruce R. Maxim Associate Professor Department of Computer and Information Science University of Michigan-Dearborn Mark Sebern Program Director, Software Engineering EECS Department Milwaukee School of Engineering Rayford B. Vaughn, Jr. Associate Professor of Computer Science Mississippi State University I'll share my own viewpoint at the end of this document. ###################################################################### Viewpoint - Coping with the Faculty Shortage James H. Cross II Chair of Computer Science and Engineering Auburn University In the spectrum of computing disciplines, I think of software engineering (SwE) fits nicely between computer science (CS) and computer engineering (CpE), although it is more tightly coupled with CS, at least for the foreseeable future. Since there is clearly a faculty shortage in CS, and SwE is essentially a subset of CS at the PhD level, the faculty shortage in SwE is at least as great as for CS. Obviously, there is no easy solution to our faculty shortage in SwE. It might be useful to describe the ideal candidate in today's terms: (1) Ph.D. in CS with specialization in SwE, (2) master's degree in SwE, and (3) experience on large software projects. The last item should be somewhat controversial, since no other engineering discipline requires faculty to have industrial experience. Over the next few years, faculty in CS and computer engineering (CpE) will migrate to SwE programs if this is where their interests are and the opportunity is available. Our current best hope for SwE undergraduate programs is to couple them with CS programs. SwE topics are prevalent in many undergraduate textbooks beginning with CS 1 and 2 (e.g., object-oriented design and programming). As a result, many CS faculty are becoming more comfortable with the notion of SwE. Those CS faculty with an interest in the traditional SwE topics (e.g., testing) will hopefully migrate to our advanced SwE courses. --jc-- ---------------------------------------------------------------------- James H. Cross II, Ph.D., Professor and Chair, Computer Science and Software Engineering, 107 Dunstan Hall, Auburn University, Auburn, AL 36849-5347, 334-844-6315 (Voice), 334-844-6329 (FAX), cross@eng.auburn.edu ###################################################################### "Is there a software engineering faculty shortage? Viewpoint" Peter B. Henderson, Butler University Does anyone have data on how many software engineering PhD graduates there are per year? How many software engineering faculty positions are to be filled each? Compare these two numbers to get your answer. Unfortunately it is not that simple. The specifications are not precise. Who is a SE graduate? What is a SE faculty position? What about current faculty who switch from/to SE, or leave academia for industry, or move from industry to academia? And other undefined parameters. If you are a CS department, hiring faculty with a practical inclination is hard. Advertising for and actually hiring one qualified software engineering faculty member is near impossible. The odds may increase in your favor if you have a software engineering program. Birds of a feather flock together. A solution to this shortage is simple, but impractical. Get industry(academia) to pay software engineers less(more) respectively. Graduating more software engineers(if possible) primarily fuels industry. Academia needs carrots to attract qualified software professionals. These could be more money(like business schools), unique academic programs leading to unique opportunities, or faculty coop programs mixing academic with industrial positions. Another potential solution is a two tier approach. Traditionally engineering faculty teach more upper division/graduate courses than CS faculty. Attrition of CS faculty is a reaction to large teaching loads, primarily lower division courses. Seek creative ways to better insulate SE faculty from overloaded lower division courses. A better solution is to make software engineering a true professional engineering discipline. Luckily the trends are in this direction, abet slowly (see footnote). Curricula focusing on rigorous, disciplined approaches to software development coupled with an apprenticeship employment model and licensing of software professionals, as in other engineering disciplines, is required. As a professional discipline, more qualified software engineers would be attracted to academia. As a corollary, fewer unqualified students would be attracted to such programs. Footnote: Did you catch the pun? ABET - Accreditation Board for Engineering Technology ###################################################################### Teaming for Teaching: Issues on Instructors and Institutions Dr. Joseph Kasser (joseph.kasser@unisa.edu.au) University of South Australia http://www.umuc.edu/~jkasser Abstract As we enter the 21st century, the demands for competent technological personnel are greater than ever. Universities wishing to meet this growing demand for education in systems and software engineering are facing a scarcity of qualified seasoned systems and software engineers who can teach the topic. This gap between the need and the capability to train personnel is not an easy one to fill. This paper speculates as to how a slight change in the relationship between instructors and institutions could affect the teaching of systems and software engineering. Introduction The gap between the need and the capability of the personnel is not an easy one to fill. Universities wishing to meet this growing demand for education in systems and software engineering are facing a scarcity of qualified seasoned systems and software engineers who can teach the topic. Consequently the instruction provided to students may not be at the level program directors and students desire. Consider how a slight change in the relationship between instructors and institutions could affect the teaching of systems and software engineering. Background Historically, universities have been repositories of knowledge and places to which students are attracted in order to acquire knowledge from the renowned academics. The university provides the infrastructure for the academic instructor to teach the graduate semester in software engineering. The infrastructure is not limited to the classroom and administrative functions; it also includes research facilities and technical libraries. The World Wide Web has, for the first time, made possible a significant change to that paradigm. Students and instructors can now attend a university without physically being present on campus. Recognition that distance education technology applies to instructors as well as to students allows the universities to attempt to alleviate the shortage of qualified instructors by augmenting their local staff and using suitable persons located outside their geographical areas in staffing the classes taught via distance education. For example, the Information and Telecommunications (ITS) Department at the Graduate School of Management and Technology (GSMT) at University of Maryland University College (UMUC) runs or has run on-line classes in software engineering subjects that are taught by adjunct faculty in Japan and Australia. Graduate seminar courses in software engineering at the GSMT are delivered in the hybrid constructivist and objectivist formats using lectures, required readings, and student projects. These seminars have traditionally been developed around textbooks and journal articles. In the last few years, web published articles have also been used as text materials. When a course is developed around the textbooks and associated reading materials, the value added by the university is in the format and structure of the course and in the persona of the instructor. In the ITS Department, these seminar courses are initially developed by the Program Director or by an adjunct professor as "works for hire". If an adjunct professor develops a course, the adjunct professor normally goes on to teach the course in the program. Staff or adjunct personnel also teach other existing courses. It is the instructor who embellishes the lectures and discussions with anecdotes based on experience and other source materials not on the list of student required readings. Because it is the instructor who embellishes the course materials and makes them come alive to the students, each class, as taught, is slightly different. An alternative paradigm Before reading the next section, note that universities are already purchasing courses that they do not have the resources to produce on their own. Consider the effect of changing the relationship between the university and instructor from that of employer - employee to that of customer - contractor. Imagine a university with no full-time teaching faculty! Instead, the universities meet the need for instructors by issuing tenders for subject matter experts to create, teach and maintain complete courses in the systems and software-engineering curriculum. The universities publish requests for proposals (RFP) for course material useable both in the classroom and via distance education on web sites and electronic journals such as the one you are reading. The RFP could also contain the Web URLs of the templates and standards for formatting the course material. The required material would comprise course materials, lecture notes, and even PowerPoint transparencies with audio accompaniment on a topic. Responses to the RFP could come from various places including: * The research faculty at the institution. * Research faculty at another institution. * Another teaching university. * Practitioners in industry; the traditional adjunct professors. * A Company that provides training in software engineering. * Subject matter experts who can't or don't have the time to teach, teaming with teachers who have some knowledge of the subject. The university would evaluate the offers based on whatever criteria the institution chooses to use. These criteria could include: * reputation of the instructor, * publications in the field, * student evaluations, * teaching experience, * cost of course, * delivery mechanism, * quality of materials, * the frequency of upgrades in a multi-semester course. * degree of currency of reading material, and * other. The competition would encourage the instructors to keep the material current. The institution could choose to tender for a single course, or the same course to be provided several times in several years. At this level there is no difference between this paradigm and the current situation as far as the students are concerned. However, the effect of this change could serve another purpose. The instructor's perspective Now look at the situation from the perspective of the instructor. The fee paid by the institution for producing and teaching one new course does not in general cover the costs to produce the course, teach it, and grade student work at a reasonable hourly rate. Currently, adjunct instructors primarily teach for reasons other than money. These reasons include the: * Desire to be associated with the university, either for the glamour or for the library resources. * Desire to pass on their knowledge and experiences to the next generation of systems and software engineers. * Thought of transitioning from industry to academia in the future and the consequent need to build up teaching experience. Yet academia in most universities is much more than teaching, and the skills and expertise developed by a career in industry are the factors that make a person a desirable teacher, but not necessarily a desirable full-time member of the faculty. People who wish to transfer from industry to academia may not have the: * Research skills needed in the traditional university. * Administrative skills needed to deal with students outside the classroom in the role of a help desk operator providing advice and slicing away at red tape to facilitate the education of the student. These skills are a requirement in a teaching university like UMUC. Could this new paradigm provide these adjuncts with their desired career transfer in a way that does not bring them into the traditional full-time academic positions? If the financial rewards were worthwhile, it might. So read on. What would happen if instructors could tender courses on a non-exclusive basis? Non-exclusive courses mean that the instructor is allowed to teach the course at more than one institution via distance delivery or by short intensive courses lasting a week. There is no intention to allow an instructor to deliver the same course in the classroom in different universities in the same geographical area. If instructors could teach the same course for more than one university, the potential number of students increase and so does the financial reward. In this situation, each institution offers the class and the instructor delivers it on behalf of the university. However, this is still the traditional paradigm in which the students come to the universities. What if, instead of the instructors subcontracting to the universities, the universities come to the following agreement with the instructors? The instructors offer the courses and the universities administer the enrollment of the students in the class and pay the instructor on a per student basis. In this scenario there may be students from several universities taking the same class, working in teams together as if they were all in the same school, yet the instructor would file grade reports to the several institutions at the end of the semester! Too far fetched for you? Well, for your information, a Division of a major US Defense Contractor in the Washington DC Metro area has developed three graduate level face to face classes in systems engineering and telecommunications for its internal leadership development program. Each of the classes is accredited with four major universities. Employees in the contractor's program seek admission to one of the universities to pursue a graduate degree. They take the regular university's classes, as well as the three classes mentioned above. When the in-house class runs, the administrator has to report the student grades to the specific university in which the student is enrolled. That means grade reports can go out to up to four universities. In the distance education environment, the students could be located anywhere on or near the planet as long as they have an Internet connection. This scenario also has an impact on subjects that are taught infrequently at any single institution due to the lack of student demand and the financial loss of staffing a class attended by few students. In such a situation the student has to: * Forgo the class - the student looses. * Wait until the class is offered - the student may or may not be able to work out a schedule of classes to accommodate the delay. * Take the class at another institution and transfer in the credits - the university loses the tuition payments. Experts in the field could increase their income from teaching a class each semester by filling it with students from several institutions. This is a win-win-win scenario in that: * The instructor benefits by the greater earnings from teaching. * The student benefits by the availability of the class when the student needs it. * The institution benefits by collecting the tuition because the class is not transferred in. Common to all threads in this scenario is the global experience gained by the student in working with other students across institutions. Multiple awards Now speculate a little further. What if, instead of the RFP being for a single award, the university made multiple awards in the manner of a United States Government multiple-award task-ordered contract. When an institution received several offers that met its requirements, it could award the opportunity to provide the course to all qualified offerers and the students could take the class with their instructor of choice. For example, the university would announce that for 2001, any one of the classes in systems engineering offered by a list of approved instructors would be accepted as meeting the student requirement to take the course. The university would provide the students with pertinent information about the instructor and the course, and pay the instructor on a per student basis. This competition would raise the quality of the education and also provide students with alternatives. For example a course on the software lifecycle can be taught by different instructors in different ways. One instructor could be more formal and mathematical than another within the context of the same syllabus. This happens in the current paradigm. If the university is big enough and there are sufficient students, the university may run two sections of a class and the students choose if they want the version with or without the mathematics. In this paradigm, both versions would be available to students in smaller institutions. For the smaller institutions, this scenario provides the same benefits as teaming with larger institutions. It allows them to offer more degrees than they could on their own. Since the syllabi will be published there will be a convergence between the syllabi on specific topics as taught by different instructors. The differences will be in the persona of the instructor. This might allow different instructors to charge more or less for their courses depending on their workload, their reputations or some other factor. Students may be prepared to pay slightly higher tuition rates for certain instructors, and the institution gets its percentage. The convergence of syllabi may lead to greater uniformity in what is actually taught in graduate degrees in systems and software engineering. Intellectual property issues In this alternative paradigm, the instructors own the rights to the content of the course; the university owns the rights to the information in the specific institutional format. This is similar to the way authors and publishers split the rights to the textbooks. This is a simple division and totally bypasses problems in the current paradigm. Here's an example of a problem that would be eliminated by this paradigm. The GSMT at UMUC (http://www.umuc.edu) offers a Master of Software Engineering (MSWE) degree. Students may take classes in the classroom or via distance education. The curriculum contains one of the few graduate level classes on Software Maintenance (MSWE 648) (Kasser and Kerby 1999), and one of the still fewer classes on the topic available in via distance education. The course content was developed by the Program Director in 1998. He also taught the class for three semesters. As creating the course and upgrading it each time he taught it was part of his duties, the program director created a "work for hire" and UMUC owns the course. The program director has since left UMUC but continues to teach the course as an adjunct professor. The course is scheduled to run in two sections (classroom and distance mode) in spring 2000 and needs upgrading. The module on Y2K needs a major upgrade and some of the other modules need minor tweaks to stay current. The adjunct is going to make the upgrade. Who owns the rights to the upgraded parts of the course? If the course remains at UMUC and is only taught in the classroom and via distance education, the matter is not very serious since UMUC and its students are the only beneficiaries of the changes. However, UMUC has begun to offer its courses to other institutions. Since MSWE 648 is one of the few graduate level classes on the subject of software maintenance, it should be a very marketable course. Thus the ownership of the intellectual property has financial implications to the person who modified the course. Conclusions This article has covered some initial thoughts on an alternative relationship between instructors and institutions and the implications of the changes in the relationship. If the model is adopted, there could be a fundamental change in the nature of the university in the area of software and systems engineering. The institution would no longer be a place where students come to learn from academic leaders, it would however still be a place that provides the infrastructure for learning as well as continuing its role in providing graduate students with research opportunities. What do you think? What's in it for me. I developed MSWE 648 when I was at UMUC (Kasser and Kerby 1999), and continue to teach it as an adjunct professor, so the intellectual property issue is very relevant. I'm now at the Systems Engineering and Evaluation Center at the University of South Australia (UniSA). I'm in a research role without the requirement to teach. However, since I like teaching, I'm developing two graduate level courses in systems and software engineering. Since I'm not required to teach at UniSA, the courses are mine, and will probably be delivered at UniSA under a separate contract. I'm also well versed in distance learning techniques and could teach them via distance education using audio enhanced lectures or via the short one-week intensive seminar model. The courses are in: * Requirements Engineering, and * Software Engineering Project Management Requirements Engineering The aim of the course is to equip students with the appropriate understanding of the difficulty of writing good requirements, the use of requirement management as an approach for controlling change and measuring the degree of completion of a project over the development, build, test and deliver, portion of the system and software life cycle. On completion of this subject students should be able to: * Elicit requirements from customers; * Write verifiable requirements; * Critique and clarify poorly written requirements; * Evaluate COTS products for degree of conformance to project requirements; * Use the Categorized Requirements in Process (CRIP) (Kasser 1999) approach to measuring the degree of completion of a development project. Software Engineering Project Management The aim of the course is to equip students with the appropriate understanding of the reasons for the failures of software development projects, the factors leading to cost and schedule overruns in software development projects, the rational and application of industry standards to the software environment, and alternative architectures that minimize defects in developed software. On completion of this subject students should be able to: * Understand the defects in the current software project management paradigm; * Identify major causes of cost and schedule overruns; * Shape software designs into a testable framework; * Develop software build plans that allocate high priority requirements to early builds; * Apply Industrial Engineering principles to software project management. Anyone with an interest in trying out some of the ideas discussed above using these courses as prototypes please E-mail to joseph.kasser@unisa.edu.au. References Kasser, J.E., Kerby, S., Teaching Software Maintenance Online via (Mostly) Asynchronous Distance Learning , Forum for Advancing Software Engineering Education (FASE), Volume 9 Number 10, October 15, 1999. Kasser, J.E., Using Organizational Engineering to Build Defect Free Systems, On Schedule and Within Budget, Portland International Conference on Management of Engineering and Technology (PICMET) 1999, Portland, OR, 1999. ###################################################################### Teaming for Teaching: Producing Effective Systems and Software Engineers for the 21st Century Dr. Joseph Kasser (joseph.kasser@unisa.edu.au) University of South Australia Abstract As we enter the 21st century, the demands on our technological personnel are greater than ever. Universities wishing to meet this growing demand for education in systems and software engineering are facing a scarcity of qualified seasoned systems and software engineers who can teach the topic. This gap between the need and the capability to train personnel is not an easy one to fill. This paper applies an industrial solution to the problem faced by individual universities, namely synergistic teaming to provide educational opportunities greater than those can could be provided by the individual institutions. INTRODUCTION As we enter the 21st century, the demands on our technological personnel are greater than ever. For example: * Major government funded systems development has traditionally been characterized by cost and schedule overruns and other (spectacular) failures. * Employers need effective systems and software engineers to meet the demands of producing modern complex systems within the constraints of schedule and budget. * Building modern complex systems with international subcontracts and partners requires that the builders have a global perspective. This gap between the need and the capability of the personnel is not an easy one to fill. Universities wishing to meet this growing demand for education in systems and software engineering are facing a scarcity of qualified seasoned systems and software engineers who can teach the topic. Consequently the instruction provided to students may not be at the level program directors and students desire. This paper proposes applying an industrial solution to the problem faced by individual universities, namely synergistic teaming to provide educational opportunities greater than those can could be provided by the individual institutions. The traditional approach of teaching theory in academia does not work too well in systems and software engineering because it is a field that is evolving rapidly. By the time a methodology gets into a syllabus the state of the art has moved on. In addition, while there are few proven theoretical methodologies in the field, any literature search of the field will show there are a lot of empirical approaches that have been published as symposia papers. Luckily, the part-time or adjunct faculty teaching systems and software engineering tend to be senior level people who are doing systems and software engineering as a full time job, and are teaching part time. These people, not only teach the theory as expressed in the text books, they are in an excellent position to comment on the theories and tell their students what works and what doesn't work. In effect they have returned to the tried and true approach to teaching engineering skills, namely the master-apprentice model. This is the teaching model adopted in the Graduate School of Management and Technology (GSMT) at University of Maryland University College (UMUC) from teaching courses in the Master of Software Engineering and Master of Science in Computer Systems Management Degrees. Even resorting to adjunct faculty does not provide enough qualified instructor candidates. While there are many experienced practitioners who could teach systems and software engineering in general they tend not to have terminal degrees[1]. The accreditation criteria for universities which requires a specific minimum of instructors with terminal degrees for teaching at the graduate level thus tends to prohibit the use of their otherwise qualified instructors and significantly reduces that pool of available talent. Universities which are able to find experienced qualified practitioners with terminal degrees hire them to teach and then may find out that, while particular persons may have an excellent grasp of the subject, they cannot teach adult learners (mature students). And, as this situation is only discovered in the classroom, it becomes a lose-lose situation. The students suffer due to the lack of instruction, the instructor goes through a bad experience, and the university loses a valuable resource. Teaming has traditionally not been viewed as a solution to this problem because universities in a geographical area are competing for students among the same population. However the advent of the world wide web coupled with the growth of distance learning technology have made teaming a viable solution to the problem in certain situations. Consider the requirements for successful teaming and the implications thereof. CONCEPT OF OPERATIONS As with any good engineering project, it begins with a vision, commonly known as a concept of operations. A team of universities, each well known in their area (geographical or expertise) offer a joint graduate degree in systems and software engineering or in any or both of the separate disciplines. As far as the team is concerned: * One or more topics is/are taught only by the institution with the recognized expertise. The University of South Australia (UniSA), for example, would provide expertise in the systems engineering topics by virtue of its association with the System Engineering and Evaluation Center (SEEC) in suburban Adelaide. * Several topics are taught by two or more institutions * The remainder of the topics is taught by all institutions in the team. * The team is made up of institutions well separated by distance. Each is located in an area with potential students. For example UniSA could team with an institution in England, another in the Washington DC area of the United States of America (e.g., UMUC) and one in India[2]. The courses are offered in several formats to suit the lifestyle of the adult learner. These include: * Traditional synchronous classroom sessions over the course of a semester. * On-line sessions over the course of a semester via distance education in synchronous or asynchronous formats. * Short three or five day synchronous seminars[3]. * The executive format of consecutive synchronous weekend sessions enhanced with web-assisted asynchronous extensions. Students take courses from the institution of choice via their method of choice. In the situation in which a course is offered by more than one institution, the students will soon learn which institution and which instructors are more suited to their needs and plan their studies accordingly. This competition for students will tend to increase the quality of the courses and ensure that they remain reasonably current. For example, several students in the now terminated joint Master of Software Engineering (MSWE) degree offered by the University of Maryland at College Park (UMCP) and UMUC did express preferences as to institutions and instructors in acquiring knowledge of specific topics[4]. While each university locates instructors, the pressure on program directors to find instructors for every course is lessened. REQUIREMENTS FOR TEAMS Theoretically forming teams should not be too difficult, in practice it will be a major accomplishment. The requirements for successful teams in academia are the same as those for successful teams in industry, namely: * Each member has something to contribute and lacks some capability provided by other members of the team. * The members have compatible cultures. In the United States there tends to be two kinds of universities, the research university and the teaching university. As UMUC and UMCP found out, incompatible cultures are a major impediment towards forming a successful team. * The institution understands the needs of, and cares for adult learners. * The institutions provide most if not all of the systems and software engineering body of knowledge, or at least the subjects taught in current degrees in systems and software engineering. * The full-time faculty at each institution have worked in the field successfully before entering into academia. * Most of the classes are taught by adjunct faculty who are doing what they are teaching. If they are not doing it while teaching, then they should have done it within the last two years. * One institution has to administer the program, the others provide the quality control. This is the principle of checks and balances. * As important as the instruction is the access to current journals and textbooks, and databases. The ability to provide these capabilities are critical when the student body is at a distance. Providing on-line access to the data is a service provided by more and more institutions, however providing access to physical books and journals is more difficult. While UPS and Federal Express can provide this capability overnight in the continental United States at a reasonable cost, the cost of providing the service internationally is still prohibitive. The international members of the team provide the physical materials in their geographical areas. In practice however, teaming will not be simple. However, it is the way of the future. Experience has already shown that it requires: * major commitments by each institution and, * personnel in each institution committed to the vision of the team and providing their students with the best educational opportunities they can. The challenge in forming a successful long-lived team is that it will be a true example of engineering a complex system and may even end up as a case study in one of its own classes. Teaming is starting to happen. For example: * UMUC and UMCP had a joint graduate program in Software Engineering. When the joint program terminated in May 1999, UMUC converted the degree to the on-line format while continuing the phase out of the joint students and as of September 1999 it was their fastest growing program (Kasser, et al.,1999). * UniSA is actively collaborating with University College, London in providing courses in systems engineering. * Informal 'teaming' is also taking place wherein individual instructors teach at more than one university. However at this time, this informal teaming does not seem to cover the situation where the same instructor teaches the same or similar classes at the different institutions. OTHER BENEFITS OF TEAMING INTERNATIONALLY Other benefits include: * The institutions in the team are not competing for students who wish to study in the classroom. * Students are exposed to other ways of doing things in other nations and cultures. This exposure comes from both the instructors and their classmates. * Students in the on-line classes work in teams on projects with people. This constructivist approach to learning provides both the global perspective and the ability to interact with co-workers in distant time zones. * Australian and British universities offer research degrees at the Masters and Doctoral levels which do not have residency requirements. By teaming with a Stateside university, the degrees would be available to the professional in the USA who does not have the time to spend in a 'residency'. This opens a new market to the offshore universities. In addition, as well as raising the effectiveness of systems and software engineering, making this type of degree available in the USA would, in the long term, provide a greater pool of subject matter experts with terminal degrees for teaching in the classroom. CONCLUSIONS Institutional teaming for teaching systems and software engineering offers benefits to both institutions and students. As such it should only be a matter of time before the first such team is formed and offers world class graduate education in systems and software engineering. REFERENCE Kasser, Joseph E., et al., "Bringing the Master of Software Engineering Degree On-line at University of Maryland University College", SETE-99, Adelaide, Australia, 1999. FOOTNOTES 1 A terminal degree is generally one at the Doctorate level. 2 England provides entry in the European Union as well as the British defense industry. Washington DC is the location of many contractors providing systems engineering services to the U.S. Government. India is a growing area in the field of systems and software engineering and students seem to be one of its major exports. 3 The short seminars allow for instructors to be flown to their students, in the manner in which UniSA personnel offer courses in the United Kingdom and makes use of foreign talent in Australia. 4 It was not at all one-sided. Some students preferred UMCP, others UMUC. ###################################################################### Kenneth L. Modesitt Professor and Chair and Bruce R. Maxim Associate Professor Department of Computer and Information Science University of Michigan-Dearborn For those readers with enough gray hair (or none!), step back in time with us to 30 years ago, say 1968-70. At that time, Computer Science (CS) programs were in their infancy. One of the authors had graduated with a B.S. in Mathematics from the University of Illinois in 1963, having become enamored with the math and EE courses that used the Illiac I (von Neumann Princeton-class 1000-word Williams-tube computer). Then he took a M.S. in CS from Stanford in 1965 (first in the nation), pursued a Ph.D. in CS from Carnegie Tech (one of the first in the nation) and took a position teaching CS at Colorado State University. There were no textbooks, let alone very few faculty with advanced degrees in CS. The (few) computers in 1967 were mostly mainframe with punched card input, and all assignments were distributed, courtesy of an over-worked ditto machine. Did CS survive this stage of infancy? You could say that!! We believe that Software Engineering will experience a similar phenomenon. CS "started" over 50 years ago, and SE was not "articulated" until 1968. To be sure, there will be shortages of people with advanced degrees in software engineering initially. However, the field will continue to grow as qualified people with degrees in CS, Computer Engineering, IS, and others will spearhead the growth. In fact, the future is even brighter, we feel, as a substantial number of people with excellent relevant experience are now in industry and the government, including the military. These individuals are a superb source of faculty, both full-time and adjunct. They possess the "trial-by-fire" experiences, and the reflective nature to appreciate the "lessons learned" from such experiences. Competition has forced them to maintain state-of-the-art competency. They perforce have had to teach others in their organizations the fundamentals of software engineering theory and practice. The only Ph.D. program for Software Engineering in the nation, available from the Naval Postgraduate School in Monterey, CA (http://www.cs.nps.navy.mil/) has students who fit the profile above. Naturally, they will be very valued additions to the profession. We, along with a whole bunch of other universities, would LOVE to hire some of them! So, yes, there will be a shortage of faculty who have a Ph.D. in Software Engineering, but that will be temporary and will not severely hamper the growth of the discipline. Kenneth L. Modesitt Professor and Chair Modesitt@umich.edu (313) 436-9145 Department of Computer and Information Science University of Michigan-Dearborn 4901 Evergreen Road Dearborn, MI 48128-1491 And another viewpoint! Based on what I have seen in our department, the SE faculty shortage is far more severe than the CS faculty situation. In addition to having very few SE Ph.D. programs, many institutions have very few graduate courses in the SE area of study. It is hard to find more than six current textbooks in the areas of User Interface Design or Software Quality Assurance (though it is possible to find books on Software Reliability). The textbook selection for a first SE course at the graduate or undergraduate levels is fairly rich (probably 20 or 30 current books) - finding good materials for an Advanced SE course is tough. I believe too that the extreme shortage of trained SE in the industrial and commercial sectors (and the high salaries offered relative to academia) makes it hard to convince students to finish doctoral degrees. There is also still a bit of snobbery among theoretical CS faculty in our department who regard SE as too applied to be real research, consequently interested students may not be doing thesis work on SE topics. It will be hard to change this situation, until more SE degree programs are up and running (BSSE, MSSE, Ph.D. or D.Eng or D.Sc). The usual approaches in the past have been to try and attract practitioners to come to academia on a part time basis and to look to retraining programs for CS, EE, and Management faculty to broaden their knowledge of SE. Summer institutes and short courses are ways of retraining. Encouraging collaborative research and publication on SE topics is another way of doing this. Integrating SE topics in traditional CS courses is a much longer solution until the faculty are in place to begin offering more separate SE courses at the graduate level. I am afraid the situation can only change slowly through natural evolution - unless something drastic changes the resources available to address the problem. Bruce R. Maxim Associate Professor Bmaxim@umich.edu (313) 436-9155 Department of Computer and Information Science University of Michigan-Dearborn 4901 Evergreen Road Dearborn, MI 48128-1491 ###################################################################### Coping with the Faculty Shortage Mark Sebern Program Director, Software Engineering EECS Department Milwaukee School of Engineering 1025 N. Broadway Milwaukee, WI 53202-3109 USA 414-277-7213 sebern@msoe.edu http://www.msoe.edu/eecs/se/ http://www.msoe.edu/~sebern/ With a booming job market for computer-related skills, it is not surprising that recruiting software engineering faculty can sometimes be a daunting task. The specific challenges may vary, however, depending on the characteristics of each educational institution. The Milwaukee School of Engineering is a university historically focused on undergraduate engineering, though construction management, business, nursing, and a number of masters programs are also offered. Applied research and interaction with industrial partners is encouraged. MSOE offers undergraduate engineering programs in architectural, biomedical, computer, electrical, industrial, mechanical, and software engineering, but not in computer science. In faculty hiring, emphasis is placed on teaching ability and experience in engineering practice. The bad news is that this emphasis limits the field of prospective faculty candidates and to some extent places us in direct competition with industry. The good news is that, for candidates seeking the type of environment we offer, we don't have a lot of competition. In recent years, we have been able to attract a number of excellent faculty. Of course, continuing enrollment growth in computer and software engineering means that the job is never done. So far, we have managed to keep up with demand (more or less well) by: 1) attracting practitioners with both academic credentials and significant industrial experience who have reached a point in their careers where a teaching position (with opportunities for applied research and consulting) is an attractive alternative, 2) selectively recruiting traditional faculty candidates (both recent PhD's and experienced professors) who have practical experience from previous employment or as a component of their academic work, together with a strong interest in teaching, and 3) providing professional development opportunities for current faculty to upgrade their skills and knowledge so they can make a greater contribution in growth areas such as computer and software engineering. Still, the challenge remains. As more software engineering programs develop, it seems likely that competition for faculty will increase. In an environment where sophomore engineering students are offered $US60K to drop out of school and do e-commerce development, academic pay levels can sometimes be an obstacle for promising prospects. On the other hand, these are exciting times for software engineering. Software engineering educators have the opportunity to exert significant influence on the development of the next generation of practitioners. I remain hopeful that we'll be able to communicate the benefits of being part of that enterprise so that we can attract the faculty needed to make it a success. And yes, since you asked, we ARE always looking for a few good profs! ###################################################################### Coping with the Software Engineering Faculty Shortage - A Viewpoint Rayford B. Vaughn, Jr. Associate Professor of Computer Science Mississippi State University Mississippi State, MS 39759 vaughn@cs.msstate.edu (662) 325-7450 This author was absolutely delighted when contacted by Don Bagert and asked to provide a viewpoint for FASE on whether or not we are faced with a shortage of software engineering faculty and how to cope with it. This is an important topic for all of us as software engineering degree programs become more ubiquitous and as the discipline itself begins to take on more of its own identity. It seems clear that there is a shortage of software engineering faculty - not entirely inconsistent with the overall shortage of computer science faculty today. One only has to have experienced a faculty search effort within the last several years to arrive at this conclusion. There appears to be both a quantity and quality problem to cope with. The IEEE Computer Society and ACM Software Engineering Coordinating Committee's Accreditation Criteria for Software Engineering addresses importance of quality faculty. In fact, the criteria includes a statement that "Faculty members teaching core software engineering courses should have substantial practical software engineering experience". Herein lies a critical component of faculty requirements that will exacerbate the shortage already being experienced today. One generally obtains such experience in an industrial setting working commercially or for a government agency. Those that perform in this capacity and hold a computer science (or related discipline) doctorate are also normally in positions of significant responsibility, compensated with a salary higher than that found in academia, and not encouraged or motivated to develop a significant record of publications, teaching, or sponsored research (all academic indicators of success). The ability to demonstrate "substantial" practical software engineering experience can be defined in various ways, but one could propose that this suggests a minimum of five years experience as a software engineer. Another accreditation criteria faculty requirement is that "...faculty must be able to interact effectively with software practitioners." This suggests not only experience as a software engineer, but also project management, team leadership, customer relationships, lifecycle management, etc. Again, these qualifications at the doctorate level are rare in both the academic and commercial communities. In other words, the talent pool is sparse and the competition is keen. How does one cope with this shortage? The following tactics are presented as "thoughts" for consideration and to promote a bit of dialogue: 1. Proactively recruit from industry and government organizations. There are individuals that are looking for a lifestyle change and to whom the academic environment is appealing. These same individuals are not likely to see traditional recruitment ads (e.g., CACM or The Chronicle) and not likely to respond to such search efforts. This author has seen better results by "targeting" such individuals and working with them one on one to solicit an application. 2. Be flexible in reviewing resumes. Look for "potential" to publish and to establish software engineering research program based on years of experience and interaction in the software engineering community. It is unlikely that many applicants will have lengthy publication records accompanying years of industrial experience. This is not to say that "no" publications is acceptable either - some evidence of publishing ability and peer review needs to be established. 3. Build the software engineering faculty with a "cooperative" mix of practitioners coupled with pure researchers. This allows those without experience to leverage the contacts and experience of those who have it and encourages the more practical minded to explore new and innovative theory. The "team" must be balanced. 4. The tenure process should recognize contractual relationships between faculty and software engineering industry in the same vein that it recognizes a more traditional (e.g., NSF) research proposal. Indeed - such contracts are the research test bed for many software engineers. 5. Encourage more early "sabbaticals" with industry for young software engineering professors that are seeking experience. Today's shortage of software engineering faculty will likely continue into the foreseeable future. This is not comparable, however, to the shortage experience by Computer Science as it emerged as a discipline in the early to mid 1960's. Early Computer Science faculty were obtained from a variety of disciplines that used computers as a tool (e.g., physics, mathematics, industrial engineering, etc.). Software Engineering faculty will need to apply computer science and computer engineering to a customer environment and will therefore likely need to be largely produced by those disciplines (with some exceptions of course). ###################################################################### The SE Faculty Shortage: Deja Vu, or Something New? Donald J. Bagert Professor and Associate Chair Department of Computer Science Texas Tech University There is no doubt concerning the fact that there is currently a major shortage of faculty for all computing disciplines. In the case of software engineering, the situation is compounded by the fact that there are few doctoral programs (and apparently only one in North America, at the Naval Postgraduate School) in the discipline. At the same time, events in the U.S. and Canada regarding accreditation and licensing will likely spur the creation of new undergraduate programs in software engineering. This is similar to the situation faced by computer science in the 1960's and 1970's. So, the question is, does the solution to the faculty shortage lie in that past experience? The answer, in my opinion, is that there are some similarities, but also several differences. Among the similarities: 1. Adjunct faculty can be used in the short-term to fill some of the gap. However, adjuncts have no vested interest in the program as compared to full-time tenure-track faculty, so this was not a long-term solution for CS thirty years ago, nor it is one for SE today. 2. Software Engineering programs are growing primarily out of two different departments: electrical & computer engineering (ECE) and computer science. In the case of computer science, it was Mathematics and Electrical Engineering. As with Math and EE in the sixties and seventies, ECE and CS faculty can be retrained (or have their training supplemented) in order to become productive software engineering faculty. 3. At the same time, there are many in both engineering and computer science, even those teaching and doing research in software engineering, that believe that SE is not a separate discipline, which mirrors the situation facing CS thirty years ago. (There are some amazing parallels: computer science is a science unlike any other, since it grew out of an invention - the computer, while software engineering is a unique new type of engineering, since it concerns the engineering of a non-physical entity: software. In both cases, this has led to strong opposition to the respective disciplines.) This situation can lead to less SE faculty being needed in the short-term, because opposition to it as a separate academic discipline slows the rate growth; at the same, it means that universities may be less cognizant of the eventual need for such faculty. However, there are two major differences between the past situation in computer science and the current dilemma faced in software engineering regarding faculty, and it is in those differences that universities should concentrate their search for solutions: 1. Educational delivery systems are much more sophisticated than thirty years ago. This makes the reuse of courseware in different courses by different instructors (possibly even at different universities) more feasible, as well as aiding long-distance education. The question is: do such systems reduce the faculty workload, or merely allow for a wider range of options for the student? Formulating, implementing and evaluating potential solutions in this area have already begun, but much more work in this area is needed. 2. It will not be nearly as easy to create Ph.D. programs in software engineering as it was to create doctoral degrees in computer science, due to the current climate in academia. The 60's and 70's were times of growth of new programs for colleges and universities in the U.S. Today, few new Ph.D. programs are created; often, creating a new doctoral program means that another must be discontinued. One possible solution is joint Ph.D. programs across universities, as four universities are doing as the Master's level in the Oregon Master of Software Engineering program . Distance education could very possibly be used to help implement such programs. In any case, the software engineering faculty shortage is one that needs to be addressed sooner rather than later. Hopefully the Computer Research Association (through its Taulbee Report on Ph.D. in computer science and engineering) and the IEEE-CS/ACM Software Engineering Coordinating Committee are the organizations that are the best-positioned to do that, and hopefully, they will. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Don Bagert (Academic/Misc Editor) Last Issue's Topic: Addendum Last month, we discussed the top contributions of the century in the area of software engineering education, training, and professional (SEET&P) issues. A member of the panel, Michael Ryan, reminded me of an omission to the honorable mention list: "I still have a soft spot for the results that emerged from the IBM Federal Systems Division activities in the 70s and early 80s. I guess it's because when I was trying to put together a course on S.E. in the early 80s and looking for quantitative data I found the analysis they provided really useful. Work such as Fagin's on inspection also I think helped identify the importance of process in developing software - I remember at the time being surprised that a well organised inspection process was so much better than test data in finding errors." Thanks, Michael. I also need to clarify your affiliations, which were stated as Dublin City University and Accelerated Encryption Processing (AEP); Michael is a consultant to AEP, and not a member of the their staff. Sorry for the confusion. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Next Month's Topic: Top Ten Contributions - Don't Forget to Vote! Topic Editor: Don Bagert, Texas Tech University Don.Bagert@ttu.edu Last month, a panel of experts gave their opinions on what are the top ten contributions of the century in the area of software engineering education, training, and professional (SEET&P) issues. For the last month, we've been asking you, the reader, for your opinions of the top ten contributions, and we've already gotten many responses. If you haven't voted already, go to http://www.cs.ttu.edu/fase/topten.htm Voting will end on Tuesday 8 February 2000, and the results will be reported in the February FASE. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Call for Guest Editors and Topic Suggestions If you are interested in being a guest editor, or have any suggestions for future topics, please contact me at Don.Bagert@ttu.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### By: Don Bagert (Academic/Misc Editor) IEEE Software Roundtable: Best Influences on SE While the December 1999 FASE had a panel of seven experts express their opinions of the top ten contributions of the century in the area of software engineering education, training, and professional (SEET&P) issues, the January/February 2000 issue of IEEE Software did something similar for the entire SE field. Software Editor-In-Chief Steve McConnell organized a roundtable of twelve members of the publication's editorial and industrial advisory boards (including FASE top ten panelist Nancy Mead) to identify "The Best Influences on Software Engineering" (the title of the article) over the last fifty years. Their list consisted of: Reviews and Inspections Information Hiding Incremental Development User Involvement Automated Revision Control Development Using the Internet Programming Languages Hall of Fame: Fortran, Cobol, Turbo Pascal, Visual Basic Capability Maturity Model for Software Object-Oriented Programming Component-Based Development Metrics and Measurement (R)Capability Maturity Model is registered in the U.S. Patent and Trademark Office. This excellent discussion can be found on pages 11-17 of the January/ February issue of Software. ###################################################################### By: Don Bagert (Academic/Misc Editor) IEEE Software Letters to the Editor on Professional SE The January/February issue of IEEE Software also contained on pages 6-9 a number of letters to the editor concerning the previous issue on Professional Software Engineering. Many of the letters focused on the licensing issue, with several of those writing expressing their concerns about the licensing of software engineers. One letter contained a number of questions they felt were unanswered about the licensing issue, which was followed by a reply by Software Editor-In- Chief Steve McConnell. The role of software design, software engineering curricula, project management, and the SE body of knowledge. ###################################################################### From: Peter B. Henderson Undergraduate Software Engineering at Butler University Peter B. Henderson In 20 to 30 years from now, it will be interesting to look back at the predictions for the software and information technology fields at the turn of the century. Study of history often leads to a better understanding of the future. To capture practical applications of the sciences, engineering disciplines evolved. A typical undergraduate computer science graduate is involved with practice rather than pure science. To make computer science a truly professional discipline, it will necessarily evolve toward engineering, specifically software engineering. Similar arguments have been made in the past. With the move to license software engineers, the merging of the CSAB and ABET accreditation organizations and the potential for software litigation, the time is ripe to develop undergraduate software engineering programs emphasizing rigorous, disciplined approaches to software design and development. Our goal at Butler University is to evolve an undergraduate software engineering program. The current computer science program was recently separated from the mathematics department; hence, the beginning of one potential path of evolution: CS -> CS & SE -> SE & CS -> SE The primary foundations for a rigorous software engineering curriculum should be mathematics and problem-solving; like the other traditional engineering disciplines. Accordingly mathematics, math-thinking and problem-solving foundations must come early in the curriculum. Here discrete math will play a role similar to continuous math in traditional engineering. Students would take discrete math the freshman year, just as engineering majors are required to take Calculus I and II the freshman year. Students would still take some continuous math to gain mathematical maturity, and have exposure to both modes of math thinking. Eventually I anticipate continuous and discrete math will evolve to be equals in our institutions of higher learning, each complementing the other. A prototype freshman discrete math course may be similar to the foundations of computer science course I developed at SUNY Stony Brook, and have taught there for the past 15 years. A description of this course follows with a recent survey by alumni found at www.ic.sunysb.edu/cse113/survey/ "A rigorous introduction to the conceptual and mathematical foundations of computer science. Problem-solving techniques and mathematical concepts that aid in the analysis and solution of algorithmic problems will be stressed. The course will concentrate on general problem solving principles, recursion and induction, recursive problem solving, and discrete mathematics concepts including: sets, logic, relations, graphs, functions, sequences, induction, basic proof techniques. These concepts will be motivated within the context of computer science, and its applications. Mathematical maturity at the level of pre-college calculus is expected." Subsequent courses would build on these foundations by emphasizing rigorous approaches to designing and developing software systems. For example, in CS-I (re-titled SE-I perhaps) students could apply logic to specify pre/post conditions and invariants, and to reason about software systems. Graduates of traditional engineering programs typically apprenticeship with masters to learn their craft. Accordingly, the focus of an undergraduate software engineering program should be on concepts, problem-solving, and building strong, rigorous foundations. Practice through software development projects is essential, but would not be the primary focus. Good instincts for software design/development should be learned on the job. A related key aspect of a successful software engineering program should be some work experience, internships, summer jobs, coop programs, etc. We plan to coordinate such experiences for our students with local industry in Indianapolis requiring students to have at least two work experiences. What is the ideal curriculum for an undergraduate software engineering program? No one knows, but we will strive to evolve over the next 7-10 years the best curriculum to meet the needs of our students and industry. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Richard H. Thayer IEEE-CS State-of-the-Practice Survey As you may already know, the IEEE Computer Society is launching a new initiative to create certificates in Software Engineering and Software Engineering Project Management. This initiative, entitled the "Competency Recognition Program," is centered around the IEEE Software Engineering Standards. The Society is in the process of establishing exams for both of these certificates. Part of the procedure for establishing a certificate exam is to survey qualified engineers and managers to determine the current state-of-the-practice in software engineering and project management. In an early running of the survey there were insufficient survey participation to allow the Society to go ahead with the Software Project Managers exam (the Software Engineering survey was completed satisfactorily). In this earlier version of the survey, answers were only accepted from individuals who were currently working as project managers. This new version of the questionnaire will allow us to include people who have worked as project managers within the last ten years. This would also include individuals who while not practicing managers, are through education, training, and knowledge, qualified to answer questions about Software Project Management (check the 2-5 yrs box or the 6-10 yrs years box in Section 4.4 to indicate your level of expertise). We need 200 more good answers. So please be one of the 200. This is your chance to make a difference. Please make sure that you check one of the answers under Software Project Manager that is 10 years or less. If you have completed the survey earlier, and indicated that you were a current project manager, please do not answer it again as this will double count you. If you completed the survey earlier and answered that you were not a current project manager, please complete the survey again. This time you will be counted. The survey and is located at: http://hopper.computer.org/jobanalysis.nsf. Individuals that complete the survey can obtain a copy of the results by sending me an email indicating that you have completed and have sent in the survey. Please forward this message to others who might be qualified to take the survey. If you would prefer to complete a hard copy of the survey, please email Ms. Stacy Saul at ssaul@computer.org with your name, fax number and/or mail address and indicate that you need the Software Project Management version of the survey. If you have any questions about the survey, you can email me at thayer@csus.edu. We hope to have this wrapped up by the first of the New Year. Please submit you answers by 1 February 2000. Richard (Dick) Thayer Senior Member IEEE Computer Society ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Conference Announcements ###################################################################### From: Susan A. Mengel CSEE&T 2000 Final Program Thirteenth Conference on Software Engineering Education and Training (CSEE&T 2000) The Austin Renaissance Hotel March 6-8, 2000 http://www.se.cs.ttu.edu/CSEET2000 Final Program ------------Monday, March 6 *Keynote Address SE Coming of Age? Not Yet - James Bach, Consultant *Panel Session Software Engineering - Coming of Age or Reaching Too Far?.... D. Frailey (Chair), J. Bach, D. Dorchester, Bill Carroll, and L. Tripp *Paper Session: University/Industry A Report on Industrial Transfer of Software Engineering to the Classroom Environment R. Vaughn, Jr. Technology Transfer Issues for Formal Methods of Software Specification K. Abernethy, J. Kelly, A. Sobel, J. Kiper, and J. Powell Achieving Organization Training Objectives with Short Course Development C. Smith Lessons Learned from Teaching Software Engineering to Adult Students J. Cusick *Invited Workshop Guide to the Software Engineering Body of Knowledge: Diffusion and Experimentation Strategy R. Dupuis and P. Bourque SWEBOK and Program Accreditation G. Engel SWEBOK and the Software Engineering Education Project R. LeBlanc Production of Software Curriculum Modules G. Hislop and T. Hilburn *Panel Session Teaching Formal Methods Early in the Software Engineering Curriculum A Sobel (Chair), H. Saiedian, A. Stavely, and P. Henderson *Paper Session: Software Engineering Group Work The Effects of "Pair-Pressure" and "Pair-Learning" on Software Engineering Education L. Williams and R. Kessler A Survey on the Effectiveness of the Internet-Based Facilities in Software Engineering Education G. Succi and R. Spasojevic Student Collaboration Across Universities: A Case Study in Software Engineering 0. Brereton, S. Lees, R. Bedson, C. Boldyreff, S. Drummond, P. Layzell, L. Macaulay, and R. Young The Development and Trial of SEGWorld: A Virtual Environment for Software Engineering Student Group Work S. Drummond and C. Boldyreff ------------Tuesday, March 7 *Keynote Address An Historian's View of Software Engineering - James E. Tomayko, Software Engineering Institute *Paper Session: Software Engineering Methods Teaching Systems Analysis and Design Using Multimedia and Patterns J. Cybulski and T. Linden Student-Run Usability Testing N. Wah Experience Report: A Software Project Maintenance Course J. Andrews and H. Lutfiyya A Case Study Approach to Teaching Component Based Software Engineering A Parrish, B. Dixon, D. Hale, and J. Hale *Paper Session: Management Process Teaching Software Project Management in Industry and Academic Environments J. McDonald University/Industry Collaboration in Developing a Simulation Based Software Project Management Training Course J. Collofello The Personal Software Process(SM) in the Classroom: Student Reactions: An Experience Report S. Lisack (SM)Personal Software Process is a service mark of Carnegie Mellon University Mixing Software Project Management and Distance Education: A Case Study D. Hanlon, M. Spence, and P. Pfeiffer *Workshop Developing Graduate and Postgraduate Software Engineering Courses H. Edwards and J. Thompson The University of Durham BSc in Software Engineering and Proposed MEng in Software Engineering: A Position Paper C. Boldyreff Issues Affecting Graduate and Postgraduate Software Engineering Curricula H. Ellis, H. Younessi, and J. McKim A Model-Oriented Programming Support Environment for Software Engineering Courses C. Harrison and M. Naeem Graduate Software Engineering in Practice: First Industrial Contact R. Manderson Questions about Developing a Postgraduate Software Engineering Program L. Thomas and G. Isaacs A Graduate Course in Software Engineering L. Werner *Workshop Real-Time Computing in Software Engineering Education A. Kornecki Teaching Scientific Method for Real-Time Software Engineering D. Dampier and R. Wilson Automatic Development Tools in Software Engineering Courses J. Zalewski *Posters A Software Engineering Course that Integrates Education and Research M. Blom, A. Brunstrom, and E. Nordby Software Engineering Curriculum At The University Of Deusto R. Cortazar, A. Barredo, J. Luis Del Val The Maintainability Gap A. Dingle and T. Hildebrandt A Formation of the Career-Oriented Curriculum in the University K. Huang Domestic Control System STEM POS M. Kamkar, C. Cederberg, and J. Edvardsson, Interstel - A Seminar Model for Teaching Software Engineering N. Kubilus Software Engineering With Emphasis In Embedded System Design H. Ma Net-Centered Software Engineering Skills for the Next Millenium A. Saad The Implication of Different Thinking Styles on Software Engineering Education L. Thomas SUPER: Towards a WWW-Enabled PBL Support Environment for Software Engineering Education K. Hou Vat Change Management For Large Software Projects P. Verma Building a Next-Generation Infrastructure for the Software Education Support P. Yoon, Y. Chen, and S. Sambasivam ------------Wednesday, March 8 *Keynote Address Beyond Software and Beyond Engineering - L. Belady, Executive Director, Austin Software Council *Paper Session: Curriculum A New Software Engineering Programme --Structure and Initial Experiences P. Runeson Standards-Based Software Engineering Student Textbook E. Byrne Did We Really Teach That?: A Glimpse of Things Students (Don't) Learn from Traditional CS1 R. Duley and P. Maj A Proposed Curriculum for an Undergraduate Software Engineering Degree M. McCracken, L Hsi, H. Richter, R. Waters, and L. Burkhart *Panel Session Faculty Issues in Distance Education G. Hislop (Chair), D. Bagert, W. Doube, J. Murtagh *Paper Session: Computer Science/Software Engineering A Perspective on Three Cooperating Courses S. Mengel, L Carter, and J. Falkenberg Formal Methods: Mathematics, Computer Science, or Software Engineering? G. Tremblay A Framework Based Approach to Teaching OOT: Aims, Implementation, and Experience B. Demuth, H. Hussmann, S. Zschaler, and L. Schmitz Learning Real-Time Programming Concepts through VxWorks Lab Experiments A Kornecki, J. Zalewski, and D. Eyassu *Workshop Developing Undergraduate Software Engineering Programs M. Sebern and M. Lutz Initiating An Undergraduate Program In Software Engineering B. Carter Undergraduate Software Engineering Degrees in Australia D. Grant A Combined Curriculum Research and Curriculum Development (CRCD) Approach to Software Engineering Education B. Boehm, G. Kaiser, and D. Port *Tutorial Session Team Software Process B. Cannon, T. Hilburn, and J. Diaz-Herrera (SM)Team Software Process is a service mark of Carnegie Mellon University *Panel Session Influence of JAVA on Software Engineering Education. P. Knoke (Chair), W. Doube, J. Lewis, A. Ortiz, and A. Teruel ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Ted Baker Florida State University TENURE AND NON-TENURE TRACK POSITIONS IN COMPUTER SCIENCE Florida State University Department of Computer Science The Florida State University is in a period of significant growth in Computer Science and allied areas. The department invites applications for several tenure-track and non-tenure-track positions at all ranks. Last year the Department of Computer Science hired seven new faculty and the growth is continuing. New faculty will have the opportunity to help shape the department's future. The department's primary focus for growth is Trusted Systems, including computer and communications security, information assurance, and software reliability. We are also looking for people in areas that support and can be related to this main thrust, including system and network administration, performance measurement, software engineering, and databases. A second area of growth is Internet technology as applied to education. The recent hiring Geoffrey Fox (previously of Syracuse University) has added to an already-active program in distance learning. In a third area, the department is working with the Computational Science program to strengthen the faculty in scientific visualization and databases. For more information see http://www.cs.fsu.edu/positions/ --Ted Baker (FSU CS Dept Chair) ###################################################################### From: Byrav Ramamurthy University of Nebraska, Lincoln Computer Science and Engineering Department The UNL CSE Department invites applications for several tenure-track faculty appointments at Assistant, Associate, or Full Professor rank to begin August 2000. Applicants should have promise for innovative research and teaching in at least one of the following areas: Database and information systems Human-computer interaction Physical design or high-level synthesis Enterprise software engineering and electronic commerce Geographic information systems Distributed object technologies and middleware Computer communications and network security Theory and algorithms and hold or be completing a Ph.D. in Computer Science, Computer Engineering, or related field. Exceptional candidates in other areas will be considered. The CSE Department offers both computer science and computer engineering programs leading to BS, MS, and Ph.D. degrees and has twenty tenured or tenure-track faculty, about 600 undergraduates and 100 graduate students. UNL is Nebraska's comprehensive research university with Carnegie I standing and membership in the American Association of Universities. Last year, UNL received the second largest gift in its history to establish the JD Edwards Honors Program in Computer Science and Management. In conjunction with this program, the Department has several new named professorships. Review of applications begins December 1, 1999, and will continue until all positions are filled. A resume, statement of research and teaching interests, and three references letters should be sent to: Peter Revesz, CSE Search Committee Chair Computer Science and Engineering Department University of Nebraska, Lincoln Lincoln, Nebraska 68588-0115 See www.cse.unl.edu; e-mail search@cse.unl.edu; tel. 402-472-2401; fax 402-472-7767. UNL is committed to a pluralistic campus community through AA/EO, is responsive to dual career couples, and makes reasonable ADA accommodations. ###################################################################### From: Byrav Ramamurthy University of Nebraska-Lincoln Department of Computer Science and Engineering The Department of Computer Science and Engineering (CSE) at the University of Nebraska-Lincoln (UNL) invites applications and nominations for the position of Department Chair. CSE, with nineteen faculty, 594 undergraduates, and 105 graduate students, offers degrees in computer science and computer engineering, with programs leading to the BS, MS, and Ph.D. degrees. The Department is developing internationally recognized research and academic programs in software engineering, spatio-temporal information systems, distributed systems, and communications and networking. Qualifications: an earned doctorate in Computer Science, Computer Engineering, or a closely related field, evidence of demonstrated leadership and accomplishment in academic and research programs, and credentials appropriate for appointment as a tenured faculty member. The candidate's academic credentials or background should permit him/her to be a credible and effective advocate for CSE in both the College of Arts and Sciences and the College of Engineering and Technology. For a complete job announcement, details of the application process, and additional information about CSE and UNL, please visit http://www.cse.unl.edu/ or contact Brian Wilcox at 402-472-3130 or bwilcox1@unl.edu. Application screening will begin December 1, 1999 and continue until the position is filled. Salary will be competitive and commensurate with qualifications. Women and minorities are particularly encouraged to apply. The University of Nebraska-Lincoln is the state's land-grant institution and premiere research campus. UNL has approximately 23,000 students. The University of Nebraska is committed to a pluralistic campus community through Affirmative Action and Equal Opportunity and is responsive to the needs of dual career couples. We assure reasonable accommodation under the Americans with Disabilities Act; contact Ed Schmidt at 402-472-2891 for assistance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE The Forum for Advancing Software engineering Education (FASE) is published on the 15th of each month by the FASE editorial board. Send newsletter articles to one of the editors, preferably by category: Articles pertinent to corporate and government training to Kathy Beckman ; Academic education, and all other categories to Don Bagert . If the article for a FASE topic where there is a guest editor, the submission should instead be to that person. Items must be submitted by the 8th of the month in order to be considered for inclusion in that month's issue. Also, please see the submission guidelines immediately below. FASE submission format guidelines: All submissions must be in ASCII format, and contain no more than 70 characters per line (71 including the new line character). This 70-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. All characters (outside of the newline) should in the ASCII code range from 32 to 126 (i.e. "printable" in DOS text mode). [NEW SUBSCRIBE/UNSCRIBE INFORMATION - September 15, 1998] Everyone that is receiving this is on the FASE mailing list. If you wish to leave this list, write to and, in the text of your message (not the subject line), write: unsubscribe fase To rejoin (or have someone else join) the FASE mailing list, write to subscribe fase For instance, if your name is Jane Smith, write: subscribe fase Jane Smith But what if you have something that you want to share with everyone else, before the next issue? For more real-time discussion, there is the FASE-TALK discussion list. It is our hope that it will be to FASE readers what the SIGCSE.members listserv is to that group. (For those of you that don't know, SIGCSE is the ACM Special Interest Group on Computer Science Education.) To subscribe to the FASE-TALK list, write to and, in the text of your message (not the subject line), write: subscribe fase-talk For instance, if your name is Jane Smith, write: subscribe fase-talk Jane Smith Please try to limit FASE-TALK to discussion items related to software engineering education and training; CFPs and other such items can still be submitted to the editor for inclusion into FASE. Anyone that belongs to the FASE-TALK mailing list can post to it. FASE-TALK is also used by the editors for "breaking stories" i.e. news that we feel that you would want to hear about before the next issue of FASE comes out. (We do this sparingly, though.) As always, there is no cost for subscribing to either FASE or FASE-TALK! Back issues (dating from the very first issue) can be found on the web (with each Table of Contents) at in chronological order, in reverse order, or through ftp at . The FASE Staff: Don Bagert, P.E. -- Academic/Misc Editor, ListMaster, and Archivist Dept. of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: Don.Bagert@ttu.edu URL: http://www.cs.ttu.edu/faculty/bagert.html Kathy Beckman -- Corporate/Government Editor Computer Data Systems One Curie Ct. Rockville MD 20850 USA Phone: 301-921-7027 Fax: 301-921-1004 Email: kbeckman1@erols.com Laurie Werth -- Advisory Committee Taylor Hall 2.124 University of Texas at Austin Austin TX 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