Forum for Advancing Software engineering Education (FASE) Volume 9 Number 03 (110th Issue) - March 15, 1999 806 subscribers (see first item below) Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Letter from the ListMaster on FASE Subscriptions and the Web Site This Month's Topic: Software Engineering Body of Knowledge Upcoming Topics News Items Software Engineering Coordinating Committee Web Page Update on Canadian Lawsuit Re Use of Term "Software Engineering" Milwaukee SoE Announces New Undergraduate SE Program Software Process Improvement (SPI) Webpages FASE-TALK Discussion Thread: Growth of SE Education Calls for Participation Conference on Knowing and Learning to Design SEA '99 Position Openings Milwaukee School of Engineering University of Calgary: M.Sc./Ph.D. Studentship Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Don Bagert (ListMaster) FASE Subscriptions and the Web Site One of the interesting things about being a ListMaster is dealing with email addresses that expire or become deleted. Supposedly, both of the listserv programs that I have used supposedly allow for automatic deletion of such addresses after a certain of failures, but I was not able to get either to actually do that =) The last time that I deleted expired email addresses was before the March 1998 issue, so I guess this is the equivalent of "spring cleaning"! I found over 90 email addresses which have apparently failed to deliver FASE for three months or more, and have tried once more to contact those people. In almost all cases, that last attempt failed, so I deleted them from the subscriber list. I had know that there were a number of email problems, but I was surprised that it was over 10% of the subscriber list. I'm sure this says something about the current nature of the Internet, but I'm not sure what =) In some cases, it is merely that a user has changed servers, and thinks that the subscription should still be working correctly (possibly because they use an alias), even though it is not. We all are still getting use to doing this stuff...At any rate, I will probably do some "cleaning" more often than once a year in the future :) If you have not received FASE by the 17th of the month, it is likely that the latest issue has been sent, but is experiencing delivery problems. I always post the latest issue on the FASE web page before sending it out, you should be able to check there to see if it has in fact been published. Incidentally, I believe that there are more people that are merely checking the web site after the 15th, instead of subscribing. That's something I'll try to report on another day... If you have any problems in receiving FASE, please contact me at bagert@ttu.edu. Thanks as always for your support of FASE. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Robert Dupuis Pierre Bourque Universite du Quebec a Montreal This Month's Topic: Software Engineering Body of Knowledge Guide to the Software Engineering Body of Knowledge: Stakeholder Issues and Intended Usages Robert Dupuis Co-editor, Guide to the Software Engineering Body of Knowledge Director, Graduate Studies in Software Engineering, Universite du Quebec a Montreal Dupuis.Robert@uqam.ca Pierre Bourque Co-editor, Guide to the Software Engineering Body of Knowledge Director, Applied Research Software Engineering Management Research Laboratory Universite du Quebec a Montreal Bourque.Pierre@uqam.ca First, we would like to thank Don Bagert and the editorial team of FASE for giving us the opportunity to discuss the Guide to the Software Engineering Body of Knowledge project in this issue of FASE. We are approaching a period where we will be actively recruiting hundreds of reviewers for the project, and FASE is an important source of collaborators which we are counting on. For those who are not aware of this project, here is a brief overview. Since 1993, the IEEE Computer Society has been actively promoting software engineering as a profession and a legitimate engineering discipline notably through its involvement in the Joint ACM-IEEE Computer Society Software Engineering Coordinating Committee. This committee aims to foster and maintain software engineering as a professional computing discipline. The current chair of this committee is Leonard Tripp, 1999 President of the IEEE Computer Society. Gathering consensus by the profession on a core body of knowledge is a key milestone in all disciplines and has been identified as crucial for moving software engineering toward professional status. The purpose of the Guide to the Software Engineering Body of Knowledge is therefore to: - characterize the contents of the Software Engineering Body of Knowledge; - provide a topical access to the Software Engineering Body of Knowledge; - promote a consistent view of software engineering worldwide; - clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics; - provide a foundation for curriculum development and for individual certification and licensing material. In 1998, a Straw Man version of the Guide was written to define the project's strategy and rationale, to gather momentum in the profession and to jumpstart the Stone Man phase by proposing a draft list of Knowledge Areas of software engineering and a draft list of Related Disciplines. Based on the results of this first phase, a Stone Man version is currently being developed with the corporate support of the ACM, Boeing, Comerica, the IEEE Computer Society, the National Institute of Standards and Technology, the National Research Council of Canada and SAP Labs (Canada). The project is managed by the Universite du Quebec a Montreal. All final and intermediate deliverables of this project are or will be available free at www.swebok.org. Currently available are the Straw Man version of the Guide, the approved baseline list of Knowledge Areas for the Stone Man version, and the plan for developing the Stone Man version. The specific deliverables of the Stone Man version are a: - Consensus on a list of Knowledge Areas; - Consensus on a list of topics and relevant reference materials for each Knowledge Area; - Consensus on a list of Related Disciplines; The development process of the Guide is designed to build, over time, consensus in industry, among professional societies and standards-setting bodies and in academia. This is, of course, necessary if we wish to have the Guide adopted by as many interested parties as possible. In order to achieve this goal, the viewpoints of all stakeholders and their intended usages of the Guide need to be included and taken into consideration in the development of the Guide, at least in its review process. This must also be accomplished in a transparent and well documented manner. So far, eleven stakeholders have been identified for the Guide to the SWEBOK. They are industry (at large), practitioners, curriculum developers, small to medium-sized software organizations, trainers and educators, standard developers, researchers, regulators, licensing officials, legal representatives and students. To ensure that the needs of all stakeholders are taken into account and that their intended usages are properly understood, we are currently seeking preliminary input from these stakeholders before the first major review phase of May-June, 1999. This issue of FASE is one way of obtaining such input, especially from the curriculum developers and teaching communities. Participation in the upcoming 12th Conference on Software Engineering Education and Training( CSEE&T) and the ACM SIGCSE Symposium on Computer Science Education Conference are other sources of inputs from these groups. A workshop to be held at the International Symposium on Software Engineering Standards '99 in Curitiba, Brazil, next May will provide comments from the industry and from the standards development communities and enable us to recruit reviewers from these communities. The questions we asked in the call for this issue, published in the January issue of FASE, are still very much open. Which stakeholder viewpoints should be taken into account in the development process of the Guide and what issues are critical within each viewpoint? In other words, what uses do you see for the Guide to the SWEBOK? The articles we received are the following: 1. Tom Hilburn, well-known in the Software Engineering Education and Training community, presents the viewpoint of curriculum development. He is a prominent member of the Working Group on Software Engineering Education and Training, and, as such, has participated in the development of their Guidelines for Software Engineering Education, the subject of last month's FASE issue. He asks a few interesting questions, notably about the relationship between Software Engineering and Computer Science. In the Straw Man version of the Guide to the SWEBOK, we included a discussion about the relationship between Science and Engineering in general. Tom reminds us that the relationship between Computer Science and Software Engineering is much more complex and unstable for the moment than what is stated in the Straw Man report. Even if D. Parnas argues that Computer Science can be seen as a foundation for Software Engineering (see reference [3] from the P. Gabrini article), much remains to be said about this matter. 2. A complete description of the final draft of the Canadian Computer Science Accreditation Council Accreditation Criteria for Computer Science and Software Engineering programs, which we think will be of interest to the readers of FASE. 3. Philippe Gabrini, a colleague at the Universite du Quebec a Montreal and long-time member of the Canadian Computer Science Accreditation Council writes about the potential use of the Guide to the SWEBOK by the Council. He discusses the problems for an Accreditation body related to the use of the word "Engineering" in such an atypical engineering discipline. He describes the difficulty such bodies have in defining criteria for accrediting software engineering programs without a common view of the field. 4. Finally, Anatol Kark, of the Software Engineering Group of the National Research Council of Canada, describes the many possible uses for the guide. He reminds us that the software engineering community has the responsibility of 'doing it right', including making sure that all interested parties contribute and are heard in the development process and that no industry specific or interest group biases are introduced in the deliverables. 5. Finally, we have taken the liberty of including the Call for Reviewers and Review Captains of the Guide to the SWEBOK project. We sincerely thank the authors for their interesting and useful contributions. Please feel free to send us your opinions and comments on the questions discussed here, or on any other aspect of the project. ###################################################################### Thomas B. Hilburn Department of Computing and Mathematics Embry-Riddle Aeronautical University hilburn@db.erau.edu First, I would like to thank Robert Dupuis and Pierre Bourque (and their colleagues in this project) for their development of the Straw Man Version of the "Guide to the SWEBOK" and the three-phase plan for its full development. The development of a comprehensive Guide, along with agreement among the stakeholders on its organization and content, will be a major contribution to the advancement and maturation of software engineering as a profession. The objectives set forth for the Guide support the goals and activities of software engineering organizations, programs and projects; and they seem achievable in the time frame specified. My interest in this project is primarily concerned with the objective in the Guide to "provide a foundation for curriculum development ...". The Working Group for Software Engineering Education and Training has been working on a set of Guidelines for Software Engineering Education (see the February 1999 issue of FASE), and, if the Guide had been available at the beginning of our efforts, it would have eased and enhanced our undertaking. The Guide can be a valuable instrument in efforts to create software engineering programs in academia, especially in undergraduate programs. Undergraduate software engineering comes in all shapes and forms. There is only a handful of degrees devoted to software engineering, so most software engineering education takes place as part of a computer science program. Even though there is a growing recognition of the need for software engineers, most computer science faculty lack the software engineering knowledge, experience and understanding needed to develop curricula in this area. I believe the Guide will be a superb resource for curriculum designers. I do, however, have a couple of reservations and concerns about the organization and content of the Guide. Overall the technique for determining the proposed knowledge areas (comparison of ISO/IEC 12207 with SWE texts and programs) seems like an efficient way to determine the initial list. However, the fact that the technique failed to identify a critical area such as architectural design should caution the Guide developers to be careful and not miss the "forest for the trees". Also, I disagree with the decision to classify computer science as an "underlying discipline of software engineering". Although there are clearly ways in which computer science is an underlying science of software engineering (e.g., automata theory and complexity analysis), I believe the relationship between CS and SWE is more complex than the connection between science and engineering in other fields (like physics and mechanical engineering). Computer Science, as currently taught and practiced, has many of the attributes of an engineering discipline. In all undergraduate CS programs that I am familiar with there is a significant amount of "design" integrated throughout the curriculum (one of the principle concepts in Curriculum 91). Students typically start in CS 1 with simple design projects (analyze the requirements, create a design, implement the design, construct a product, test the product). Throughout their programs, CS students build or modify software products (simple programs, database systems, user interfaces, translators, simulators, expert systems, inference engines, etc.). However, students in physics and chemistry do not build products; they perform experiments to verify theory. In my view, computer science (at least as currently viewed) both underlies and overlaps software engineering. If computer science is treated simply as underlying science I am fearful it will be misleading and confusing to students, faculty and practicing software developers. I would suggest that the Guide developers reconsider their description of the relationship between CS and SWE. ###################################################################### From: Philippe Gabrini CANADIAN COMPUTER SCIENCE ACCREDITATION COUNCIL ACCREDITATION CRITERIA FOR COMPUTER SCIENCE AND SOFTWARE ENGINEERING Below is the final draft of the CSAC Accreditation Criteria for Computer Science and Software Engineering, being considered for adoption by the Board of the Canadian Information Processing Society. COMPUTER SCIENCE ACCREDITATION COUNCIL OBJECTIVES, PROCEDURES AND CRITERIA ABSTRACT These guidelines are written to provide assistance to anyone involved in the accreditation of Canadian university programs in computer studies and software engineering. They specify the objectives of accreditation, the various steps in the process, and the essential and highly desirable qualities of accreditable programs. Questions and suggestions for improvements may be sent, either directly or through CIPS National Office, to the Chair of the Computer Science Accreditation Council, who will ensure that they are considered. INTRODUCTION The Computer Science Accreditation Council is an autonomous body established by the Canadian Information Processing Society (CIPS). The Council has as its objectives: - To formulate and maintain high educational standards for Canadian universities offering computer and information science programs, and to assist those institutions in planning and carrying out educational programs. - To promote and advance all phases of computer and information science education with the aim of promoting public welfare through the development of better educated computer professionals. - To foster a cooperative approach to computer and information science education between industry, government, and educators to meet the changing needs of society. The purpose of accreditation is to identify those institutions that offer computer programs worthy of recognition. POLICIES The Council has adopted the following basic policies: - To accredit educational programs rather than institutions or degrees. It is recognized that programs of quite different quality may sometimes be found at the same institution and that the degree designation is considered to be the prerogative of the institution. - To invite institutions to submit programs for accreditation by the Council. - To grant accreditation only if students have graduated from the program by the time the accreditation takes place. - To favour broad programs that will prepare students to take advantage of as many different opportunities as possible, to contribute to the needs of Canadian society both in the near and long term, and to embark on life-long learning. - To deny accreditation to programs that omit instruction in a significant portion of a subject in which computer professionals may reasonably be expected to have competence. This policy is intended as a safeguard to the public and should not entail the setting of rigid standards. - To avoid rigid standards as a basis for accreditation in order to prevent standardization and conservatism, and to encourage planned experimentation. - To assess qualitative as well as quantitative factors in making an accreditation decision. This should be implemented by a visit to the institution by a competent committee, having suitable qualifications. - To accredit satisfactory programs for periods of five years. A program which nearly satisfies the criteria may be accredited conditionally for three years. When a program is conditionally accredited, the reasons will be explicitly stated, and it is expected that the institution will take action to bring the program into compliance with the criteria. - To revoke accreditation if institutions do not continue to comply with established criteria. If it appears that an accredited program is not in compliance with the criteria, then the institution is so notified. If the response from the institution is not adequate, then the Council will institute procedures to determine the actual status of the program in question prior to making any decision with respect to the revocation of accreditation. - To provide means for reconsideration. - To publish a list of accredited programs only. Information such as to whether a program not on the accredited list had been under consideration by the Council will not be made available except to the appropriate officials of the institution offering the program. An institution may not simultaneously use the same program title to identify both an accredited program and a non-accredited program. METHOD OF EVALUATION An institution's educational programs will be evaluated on the basis of data submitted by the institution in the form of a questionnaire, together with a report of an on-site visit by a carefully selected team representing the Council. The purpose of the site visit is three-fold. First, it should assess factors beyond those described in the questionnaire. The intellectual atmosphere, the morale of the faculty and the students, the calibre of the staff and the student body, and the character of the work performed are examples of intangible qualitative factors that are difficult to document in a written statement. Second, the visiting team should help the institution assess its weak as well as its strong points. Third, the team should examine in further detail the material compiled by the institution and relating to: 1. Control and organization of the institution. 2. Education programs offered and degrees conferred. 3. The basis of and requirements for admission of students. 4. Number of students enrolled: - in the college, faculty or division as a whole, - in the individual educational programs. 5. Teaching staff and teaching loads. 6. Commitment to and support for research. 7. Resources: - financial: total budget, non-salary portion of budget and salary scales, - physical: classrooms, laboratories, equipment and offices, - support staff: administrative, clerical, laboratory, research and technical, library. 8. Curricular content of the program. 9. Actual course selections, as reflected by a sample of anonymous transcripts. 10. Innovative and special features of the program. CRITERIA To assist in the identification and recognition of characteristics of programs for accreditation purposes, the following criteria have been adopted by the Computer Science Accreditation Council. Although the criteria are intended to specify minimum requirements, they also allow for and encourage two important characteristics of programs in computing. These characteristics are the diversity of programs that exist among the various institutions and the innovative features that have been typical in these programs. Innovative programs that maintain quality are encouraged. In judging a program's eligibility for accreditation, the Council will consider alternative modes of education, including variations in content, organization, and delivery. For example, many programs have adopted a format wherein students combine on-campus study with on-the-job training; the experience gained by students during their periods of employment often contributes significantly to their education. Thus such a program might be accredited partially on the basis of several required work terms in approved computing environments in place of one or two on-campus additional courses being required in computing. In the evaluation process, the principal emphases are placed on the faculty and its qualifications, the students, the curriculum, and the resources (physical, fiscal, and human). The criteria are thus divided into four sections concerned with each of these major subdivisions. It remains the responsibility of the institution to demonstrate to the Council that its program meets the spirit of these guidelines. Faculty The heart of any educational program is the faculty. A competent, qualified, and forward-looking faculty gives an overall scholarly and professionally responsible atmosphere to the operation. An excellent faculty will usually identify and overcome problems in other areas and continue to provide a program worthy of accreditation, but no degree of excellence in other areas can continually offset the handicap presented by poor faculty quality or inadequate numbers of faculty. Thus, the first consideration for a program to be acceptable for accreditation is the presence and future assurance of a continuing critical mass of quality faculty. Educational institutions seeking accreditation for computer programs must have allocated the resources necessary to achieve a critical mass of quality faculty, committed to professionalism in computing, and must be committed to maintaining the allocations required for its continuation. The proper size of the faculty depends on the enrollment and the program objectives, including amount of sponsored research, direction of graduate research, amount of extension and continuing education activities, and involvement in professional and technical societies. The size of the faculty must be large enough to provide experience and capability in a significant portion of the broad range of computer science and engineering interests and to provide meaningful technical interaction among the faculty so as to support these interests. The program must not be critically dependent on one individual. The faculty should occupy permanent positions to ensure continuity and stability. Institutions with limited enrollment and resources are encouraged to select and emphasize a smaller number of quality programs rather than to compromise standards by initiating or trying to maintain programs with inadequate faculty support. Teaching loads must leave enough time for professional development of the faculty. To function effectively as teachers, faculty members must devote a significant amount of their time to seeking new understanding through research and scholarship, industrial interaction, instructional innovation, consulting, or other professional development activities. A significant common aspect of these activities is communication of ideas to other practicing professionals, scientists, and engineers outside the home institution. Sabbatical leaves are important to faculty development, for they offer the individual an opportunity to develop professionally and allow for visiting faculty. Other evidence of institutional interest in faculty development, such as adequate resources for professional development, should be present. Students An accredited computer program must have good students. Student selection and retention standards must be appropriate to the program. When students transfer from other institutions or from a branch campus, standards for evaluation and selection of these students should be clearly enunciated, and should show that these students are of similar quality and have substantially the same knowledge as those students who have taken all their work on the main campus. When computer courses are regularly taken on other campuses, the main campus faculty should be involved with answers to questions of curricular content. A student advisory system is an important component in a computer educational program. The advisory system should embrace course selection and similar matters, and it should also include career guidance. Various aspects of professionalism and ethics may be dealt with through the guidance system. Curriculum and career guidance is best handled by well-informed faculty members who are given the time and administrative support for personal interaction with individual students. Advisors should be familiar with accreditation policies and guidelines. The level of guidance needed will be a function of the flexibility of the curriculum in a particular school. Care should be taken by advisors not to assume responsibility of choice which should be exercised by the student. Curriculum In specifying criteria for achieving accreditation in any discipline, there is a tension between establishing minimum standards and encompassing flexibility within which students can set individual goals and tailor their programs to meet diverse needs. The Computer Science Accreditation Council has adopted the following criteria to strike a balance between these objectives. The Computer Science Accreditation Council has defined criteria that can be used to accredit computer science programs and software engineering programs. The term software engineering refers to the computer science domain of knowledge defined more than thirty years ago that includes everything related to the software process. The granting of accreditation by the Computer Science Accreditation Council to software engineering programs does not have any bearing on whether the graduates of such programs are eligible for registration as Professional Engineers. I. An accredited computer program must include the equivalent of at least four years of post-secondary study (not necessarily all at the same institution) and lead to a baccalaureate degree. Furthermore, it must require that all students satisfy certain breadth and depth criteria to be eligible for the degree. The minimum breadth requirements in an accredited program are expressed in terms of equivalent years of study, as follows (in this document we mean by "year of study" an academic year during which a student is considered to have a status of "full time equivalent"): - one and one-half years of study in computer science/computer engineering/software engineering, - one-half year of study in mathematics/statistics, one year of study in subjects other than computing and mathematics/statistics. The set of courses in each area should exhibit some breath and some of the courses in each area should be at an intermediate or advanced level. This distribution leaves each student with the equivalent of one year of study to satisfy additional institutional requirements and to accomplish personal objectives. II. As an adjunct to specific areas of instruction, the program must also include training to develop students' written and oral communications skills. Not only should students be taught to present information both verbally and in writing, but they should practice collecting information through reading and listening and assembling the information for various audiences. The realization of this requirement in the program can be tailored to suit other institutional goals, but the involvement of the computer science faculty must be evident. III. Similarly to the program as a whole, the curriculum within computer science must offer a breadth of exposure along with a depth of understanding. A. Beyond introductory programming and computer usage, all students in an accredited program must be required to take courses in the following six areas, each of which is illustrated by a range of topic that might be included. This classification of subtopics is not intended to limit the scope of computing nor the areas to be included or excluded at particular institutions, but rather it is illustrative of a range of topics that an accredited program might be expected to provide. 1. Software engineering, including: a) Requirements and specification, b) Principles of software analysis, design and architecture, c) Design for embedded, real-time or distributed systems, d) Design and evaluation of user interfaces, e) Software construction, f) Documentation, tools, components, etc., g) Management of the software process, including metrics and maintenance, h) System performance, i) Quality assurance, testing, j) Software safety. In software engineering programs all of the above (a-j) must be covered (not necessarily by a full course each). 2. Algorithms and data structures, including abstract data types, established solutions to classical problems (e.g., sorting and searching), numerical and symbolic computing, database design and management, discrete and continuous simulation, search strategies for large state spaces, etc. 3. Concepts of programming languages, including programming language design and implementation; procedural and non- procedural programming languages; distributed, parallel, and concurrent processing; user interface design; etc. 4. Systems software, including operating systems concepts, virtual memory management, management of distributed, parallel, and concurrent processes, transaction processing, logging, security, computer networking, etc. 5. Computer elements and architectures, including computer organization, digital device and communications technology, logical and physical hardware design, etc. 6. Theoretical foundations of computing, including models of computation, analysis of algorithms, fundamentals of program verification, computational complexity, etc. The curriculum must require every student to have completed the equivalent of at least one course in each of the six areas. Furthermore, for computer science programs, at least one-third of the course requirement in computing must be met by intermediate or advanced courses chosen from at least two of the areas, where an intermediate or advanced course is one requiring another course from the same area as a prerequisite. For software engineering programs, at least one half year of study must comprise intermediate or advanced courses chosen from the first, third or fourth area. B. Accredited programs must prepare students to meet the computing challenges they will face after graduation, whether they embark on careers immediately or continue their education. Thus, as part of their undergraduate education, students must be well-grounded in state-of-the-art computing practices. An accredited program should expose students to several computing configurations, including varied hardware, operating systems, and programming environments. C. Aspects of professionalism are to be emphasized throughout the curriculum. Courses in social implications of computing may also be offered, but ethical and legal issues surrounding computing, including social responsibility of programmers and computer users, must be included in many courses so that students learn that these aspects are part of computing, not merely tangential disciplines. D. A significant component of an accredited program must be practical in nature; students must have direct experience with non-trivial problem-solving. This component will help to develop students' creativity in solving open-ended problems through practice in formulating problem statements and specifications, considering alternative solutions, determining feasibility and cost, and communicating the results including detailed systems descriptions. Projects and courses that require teamwork are strongly encouraged. Whereas practical aspects should be included at all levels of the program, the major portion of the practical component is to be satisfied in advanced courses. Students, individually and as members of teams, must be required to design and implement a system, program, process, or device to achieve stated objectives. Throughout the design process, decision-making must include the application of basic sciences, mathematics, computer sciences, and business fundamentals. The problem solution should include the establishment of objectives and criteria, analysis, synthesis, documentation, implementation, testing, and evaluation. It is desirable that problems include a variety of realistic constraints such as economic factors, performance thresholds, ergonomics, compliance with standards, interoperability with other systems, and conformance to ethical, professional and legal restrictions. IV. Computing applications can be found in all human endeavors, so education in any discipline outside computer science has the potential to prepare students in a field of direct relevance to their future livelihood. The diversity of backgrounds needed by various computing professionals necessitates flexibility within these accreditation requirements. Innovation in establishing institutional requirements or in promoting each individual's ability to reach personal goals is encouraged. Nevertheless, this section identifies topics that enhance a program's ability to meet the needs of computer science students. As before, the goal of breadth in exposure must be balanced by the goal of depth in understanding, which can best be achieved through the selection of complementary courses having a common focus. The mathematical content included in an accredited program's requirements should include coverage of differential and integral calculus, Boolean algebra, logic, probability and graph theory. Other topics of particular relevance to computing should also be offered, including a selection from linear algebra, set theory and modern algebra, numerical analysis, differential equations, statistics, optimization, and queuing theory. For software engineering programs, the mathematical contents should necessarily include discrete mathematics as well as probability and statistics. Outside of computing and mathematics courses, students should be encouraged to choose courses in the following two areas: a) science, engineering, or business; b) humanities or social science. Computer science students should have a half year in each area. Software engineering students may have a heavier weighting in area a, but should have at least three courses in area b. Topics in physics and electrical engineering are basic to many aspects of computing, and courses in these areas are particularly encouraged. Challenges such as endeavors to map the human genome underline the value of education in other fields of natural science as well, including chemistry, the earth sciences, and the life sciences, especially when integrated with computer studies. A thorough grounding in business fundamentals is important to prepare students of computer science to contribute to Canadian industry. Relevant courses in this area include particularly accounting, business organization, economics, and auditing, but also include marketing, personnel management, and production management. Students in computing must also be educated in non-technical disciplines. Through courses in humanities or social science, students will gain understanding of political theories and processes, knowledge of individual and group social interactions, appreciation of cultures and history, sensitivity to the literary and fine arts, and fluency in languages. Not only is this important background for future self-study, but several aspects have direct bearing on particular areas of computing: linguistics is central to natural language processing, cognitive science provides mechanisms to evaluate human-computer interaction, law can be applied to assessing liability of computer professionals, and ethics helps to evaluate social implications of computing. Resources An accredited program must have buildings, offices, laboratories, computing facilities and equipment, support staff, fiscal resources that are appropriate for the characteristics of the program that is being undertaken, and evidence to this effect should be presented. The availability of computing resources and support staff to a program in computing is of vital importance. An appropriate variety of computational and network facilities must be readily accessible to all students and faculty, and access should be provided not only during scheduled laboratory class hours but also at other times. Minimal computer downtime, reasonable access, and competent programming support staff are essential. There should be a regular plan for updating equipment and discarding obsolete equipment. Reliable and fast repair service together with a modest amount of equipment duplication is essential. The program must have competent clerical, administrative, and technical support and services. Salary budgets must be consistent with the faculty size and student enrollment. Current expense budgets must allow reasonable amounts of travel and supplies. Computer budgets must allow students and faculty enough computer time that they use it as an effective learning aid. There must be adequate access to library materials and other intellectual resources to support the program. The collections must be maintained and refreshed so as to remain current, and there must be a breadth of materials included. Electronic networking sufficient to provide students and faculty access to external resources is also important. PROCESS The following procedure is intended to serve as a guide to the accreditation process. While it is not intended to be rigid, the amount of flexibility should be kept to a minimum so that all institutions that are being subjected to the accreditation procedure are treated as uniformly as possible. Ideally the process should begin by an informal exchange between the institution and the accreditation council (possibly via the CIPS National Office). The result of this exchange will be the transmittal to the institution of documents containing details of the aims of accreditation, how the process will be carried out and the formal steps that must be utilized to initiate the procedure. On the basis of this initial exchange by telephone, letter or direct conversation, the institution decides whether or not it wants to proceed with accreditation. In the first formal step towards accreditation, the Dean of the faculty concerned must write a letter to the Chair of the Accreditation Council requesting that specific programs be considered for accreditation. The Chair of the Accreditation Council will respond, also in writing, with a proposed timetable of the process and the detailed questionnaire which is to be filled out by the institution in question. Once the questionnaire is completed, it is returned to the Accreditation Council where it will be reviewed at their next Council meeting. It should be noted that the completed questionnaire is confidential and will not be released to anyone who is not a member of the Accreditation Council or the site-visit team. During the review process it will be decided if the programs are suitable for accreditation, a visit team Chair will be assigned and the team members selected. This process may extend over one to two months, since each of the members of the visiting team will have to be approached to determine their availability. Once a team (of at least three members) has been selected, the institution is notified of the team membership and the exact dates of the visit. The institution will be asked to prepare textual descriptions of factual information that will form the basis of the report. The two-day visit then takes place, and when completed, the team Chair prepares the visit report and submits it to the Chair of the Accreditation Council. After review by the Council, the report minus the accreditation decision is sent to the Department Head, and a response solicited. This preliminary response is requested in order to ensure that any negative or less than satisfactory results may be clarified right away. It is important to ensure that misunderstandings do not occur and that all communication be kept confidential. Once the institution has been given the opportunity to respond, the report and the response are then reconsidered, and the final report, including the decision of the Council, is produced and sent to the institution. Once this occurs, positive results are made public. Appeal Process If an applicant institution wishes to appeal a negative decision of the Computer Science Accreditation Council (CSAC), the appeal must be submitted in writing together with the appeal fee of $500 (plus GST or HST) to the Chair of the CSAC at the CIPS National Office in Toronto within 30 days of receipt of the Council's decision. The appeal should set out the case for re-consideration and must indicate clearly what aspects of the application the institution believes have been inappropriately considered by the Council. Upon receipt of the appeal, the Chair of the CSAC will convene a sub-committee. The sub-committee will coordinate the appeal and prepare a recommendation for the CSAC. The appeal process will be dealt with on a timely basis. When an application is received by the Chair, the appropriate materials will be distributed to the sub-committee members within one business week. Where possible, all Council members will take part in all decisions regarding the appeal, as they do in the original decision to reject an application. At the discretion of the CSAC, a representative of the appealing institution may attend a hearing of the CSAC to discuss their appeal. The institution will be informed of the CSAC's decision by registered mail. If the appeal is successful, the Appeal fee of $500 will be refunded. ###################################################################### HOW DOES THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE AFFECT THE CANADIAN ACCREDITATION PROCESS FOR SOFTWARE ENGINEERING UNDERGRADUATE PROGRAMS? Philippe Gabrini, I.S.P., Departement d'informatique Universite du Quebec a Montreal, Canada Do you remember where you were and what you were doing in October 1968? I do, as I was happily writing assembly language code for the bi-processor Exec 8 operating system for the Univac 1108 mainframe computer. Like almost everybody else, I was totally unaware that the term "software engineering" had just been coined by two Algol 60 men, F. L. Bauer and L. Bolliet (my own doctoral thesis adviser)[1], computer scientists involved in programming languages and compilation. Little did we know that we were in dire need of software engineering to implement our software systems! After all, the Exec 8 system was operating! And of course how could I have known that 30 years later I would be involved in the definition of accreditation criteria for undergraduate programs in software engineering? C'est la vie. In Canada, accreditation movement was started by a professional society, CIPS (Canadian Information Processing Society, www.cips.ca), which was founded in 1958. Under its auspices, the University Accreditation Council was formed in 1979, preceding the CSAB by a few years, and started the accreditation of computer science programs. Nowadays, the accreditation is the responsibility of the Computer Science Accreditation Council which is still sponsored by CIPS. Envisioning a future fully licensed profession, CIPS has also been involved in the certification of computer professionals since 1989, through the Information Systems Professional of Canada designation (I.S.P.). Professional certification provides an assurance that the holder has attained the designated professional qualifications, and accreditation provides one measure to the Certification Council, which reviews the I.S.P. applications, which is that the graduate from an accredited program has met all the academic requirements that effectively prepare the graduate to function and excel in the systems environment found in modern business. More recently, the Computer Science Accreditation Council was asked by a number of computer science departments to consider making accreditation possible for a number of undergraduate software engineering programs that had already been developed and implemented. This need developed at a time when the Canadian software engineering community was torn by a struggle between the CCPE (Canadian Council of Professional Engineers, www.ccpe.ca) and the Computer Science community. In connection with the disagreement, the CCPE took to court the small Computer Science Department of Memorial University in Newfoundland which had implemented a software engineering bachelor's degree program like other computer science departments, and which retaliated by registering "software engineering" as its own trade mark! Ah, the legacy from 1968! This struggle is not over, but in the meantime software engineering programs do exist, need accreditation and cannot really wait for an eventual resolution of the conflict. The Computer Science Accreditation Council has thus gone ahead and defined criteria for university undergraduate software engineering programs. At the time, the SWEBOK project had not started and the council had to use whatever documents existed in order to achieve a meaningful definition. This operation made it clear that defining the software engineering discipline was not a trivial task, even though the council concentrated on software development. The problem was that the number of sources was not large and that finding a common denominator was hard. Had the final SWEBOK existed, the council would have used it extensively as a base to define their criteria, instead they used what was available at the time and resigned themselves to working in parallel with other bodies. At the time, the IEEE CS/ACM Steering Committee for the Establishment of Software Engineering as a Profession had started work by establishing a number of task-forces and the Council used what was already available (a draft code of ethics for software engineers, a pilot survey on software engineering and a draft of accreditation criteria)[2], even though some documents were still in early infancy. Also available was the article by D. L. Parnas[3] stating his personal views, which were not not extremely helpful as they encompassed most of applied computer science. As mentioned earlier, some software engineering programs were already in existence in Canadian universities; the available information used by the Council was thus completed by the descriptions of various software engineering bachelor's degree programs or program options from universities across Canada, including but not restricted to Memorial University and the Universities of Toronto, Ottawa, Calgary, Western Ontario, Saskatchewan and Victoria. The council worked with these documents and tried to find a common denominator. What was reached was a consensus of the council members, based on the sources used. So the Council ended up with a list of ten components of software engineering: a) Requirements and specification, b) Principles of software analysis, design and architecture, c) Design for embedded, real-time or distributed systems, d) Design and evaluation of user interfaces, e) Software construction, f) Documentation, tools, components, etc., g) Management of the software process, including metrics and maintenance, h) System performance, i) Quality assurance, testing, j) Software safety. Now that the Council has adopted these draft criteria (still awaiting CIPS Board approval) for the accreditation of software engineering programs[4], once they will be officially adopted they will be merged with the existing computer science criteria[5]. The SWEBOK will still be very useful to the council members when it becomes available as they will have to refine and update their criteria. And, now that the Straw Man version [6] of the SWEBOK is available, it is gratifying to the Council members to see that they were not off-base and that the Straw Man version validates their choices. Indeed, components c), d) and j) above are part of its Table 3, while components a), b), e), f), g), i) are part of its Table 1 and components f) and g) are part of its Table 2. So, to answer the title question, it is clear that the final SWEBOK will affect the future Software Engineering accreditation criteria in Canada. What we can see happening with the gradual definition of the SWEBOK is that the overall limits of software engineering will become better defined, as will the limits of its various components. Also, the existence of a common SWEBOK will solve the current problem of vocabulary, once everybody adopts the terms used in the final version of the SWEBOK. Finally, the grouping of various components will also be better defined, which should help eliminate any ambiguities that might exist in the current criteria. All this to say that the Canadian Computer Science Accreditation Council will certainly adapt their current criteria and its contents to the final SWEBOK when it appears. Ideally, the SWEBOK should have been defined first, and only then should the various programs and the accreditation criteria have been defined; but, ideally, in 1968 our forebears would not have saddled us with the term software engineering. After all, even though I am an "ingenieur" myself I still fail to see any similarity between building bridges (admittedly I only designed bridges in engineering school) and building software systems, or even just between bridges and software systems. References [1] Naur, P. Randell, B. "Software Engineering" Report on a Conference Sponsored by NATO Science Committee, Garmisch, Germany, October 1968, Chairman: Professor Dr. F. L. Bauer, Co-chairman: Professor L. Bolliet, Dr. H. J. Helms, January 1969. [2] Joint IEEE Computer Society and ACM Steering Committee for the Establishment of Software Engineering as a Profession: Software Engineering Code of Ethics and Professional Practice, Report on Analyses of Pilot Software Engineer Survey Data, Draft Accreditation Criteria for Software Engineering. www.acm.org or . [3] Parnas, D. L. "Software Engineering Programmes are not Computer Science Programmes", McMaster University, Report No. 361, April 1998 [4] Gabrini, P. "Canadian Computer Science Accreditation Council Accreditation Criteria for Computer Science and Software Engineering", in this issue of FASE. [5] Computer Science Accreditation Council Objectives, Procedures and Criteria, CIPS-CSAC, 1998 [6] "Guide to the Software Engineering Body of Knowledge: A Straw Man Version", . ###################################################################### Anatol W. Kark, Leader Software Engineering Group Institute for Information Technology National Research Council of Canada Two intertwined trends have existed throughout the world for at least ten years. First, the software industry is trying to find a way to become more productive and to produce software of a better quality to meet the growing expectations of their customers. This has led to a second trend - that of trying to define what software engineering is and how to make sure that those who practice this profession can help the software industry achieve its goals. Software production is, in the opinion of many, still an art, an expression of the "power of mind over matter". This attitude needs to be modified. While it will always be true that software production is an individual, mental exercise, those individual efforts must be combined, planned and controlled, and yield results that can be verified. The Guide to the Software Engineering Body of Knowledge (SWEBOK) project, initiated by the IEEE Computer Society, has a real chance of coming to a consensus as to what software engineering is, and what knowledge and skills one needs to have to call oneself a software engineer. The body of knowledge defined by the SWEBOK project can potentially have many applications. A body of knowledge is necessary for the recognition of any discipline. It can be used as a self-assessment by any software professional, and, it can also be used by certification and licensing bodies. Universities can use it to set software engineering curricula and the industry to define job requirements. But, if we are not careful, the same people can also abuse it - one can easily imagine an unscrupulous human resources person causing a job description to show that a certain individual does not fit into a given position. It is therefore extremely important, that we, the software community, do it right. "Doing it right" here means that the content of the Guide to the SWEBOK will be created by a consensus, that the process of getting to that consensus must be transparent - the community must be aware of, and understand the decision processes taking place and what the data supporting such decisions are. Doing it right also means that no biases of a specific industry or interest group are built into the resulting Guide to the SWEBOK and that there exists a mechanism for updating the Guide. The National Research Council of Canada, through its Software Engineering Group (SEG), recognizes the significance of the Guide to the SWEBOK project, wants to contribute to the success of the project and ensure that the conditions for success are met. NRC is involved in the development of the Guide to the Software Engineering Body of Knowledge both at the Industrial Advisory Board and the Knowledge Area Description level. Dr. W. Morven Gentleman is a member of the Industrial Advisory Board, while Dr. Khaled El Emam of SEG is the Knowledge Area Specialist for the Software Engineering Process Knowledge Area. ###################################################################### Call for Reviewers and Review Captains Guide to the Software Engineering Body of Knowledge Project Since 1993, the IEEE Computer Society has been actively promoting software engineering as a profession and a legitimate engineering discipline notably through its involvement in the Joint ACM-IEEE Computer Society Software Engineering Coordinating Committee. This committee aims to foster and maintain software engineering as a professional computing discipline. The current chair of this committee is Leonard Tripp, 1999 President of the IEEE Computer Society. Gathering consensus by the profession on a core body of knowledge is a key milestone in all disciplines and has been identified as crucial for moving software engineering toward professional status. The purpose of the Guide to the Software Engineering Body of Knowledge is therefore to: - characterize the contents of the Software Engineering Body of Knowledge; - provide a topical access to the Software Engineering Body of Knowledge; - promote a consistent view of software engineering worldwide; - clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics; - provide a foundation for curriculum development and for individual certification and licensing material. In 1998, a Straw Man version of the Guide was written to define the project's strategy and rationale, to gather momentum in the profession and to jumpstart the Stone Man phase by proposing a draft list of Knowledge Areas of software engineering and a draft list of Related Disciplines. Based on the results of this first phase, a Stone Man version is currently being developed with the corporate support of the ACM, Boeing, Comerica, the IEEE Computer Society, the National Institute of Standards and Technology, the National Research Council of Canada and SAP Labs (Canada). The project is managed by the Universite du Quebec a Montreal. All final and intermediate deliverables of this project are or will be available free at www.swebok.org. Currently available are the Straw Man version of the Guide, the approved baseline list of Knowledge Areas for the Stone Man version, and the plan for developing the Stone Man version. The specific deliverables of the Stone Man version are a: - Consensus on a list of Knowledge Areas; - Consensus on a list of topics and relevant reference materials for each Knowledge Area; - Consensus on a list of Related Disciplines; To be successful, the Guide to the Software Engineering Body of Knowledge project requires the contribution of a large number of people. An underlying principle of this project is consensus-building within the international software engineering community, which of course implies a large number, and a wide spectrum, of contributors. We are currently seeking Reviewers and Review Captains for the following Knowledge Areas: - Software Requirements Analysis - Software Design - Software Construction - Software Testing - Software Evolution and Maintenance - Software Configuration Management - Software Engineering Infrastructure - Software Quality Analysis - Software Engineering Management - Software Engineering Process ----------------------Reviewers--------------------------------------- Reviewers are responsible for: - Reading the Knowledge Area description and consulting the reference material provided by the KA Specialist - Providing comments from one specified viewpoint The criteria for selecting Reviewers are: - Knowledge in the Area; - Availability; - Ability to give articulate, constructive comments; - Representative of one of the viewpoints that we will identify: software engineering practitioners, academia, standards developers, regulators, etc. Schedule. The plan is that the Reviewers will be called upon to contribute during the May 3 to June 18, 1999, period. For further information or to submit candidate Reviewers (name, affiliation, Knowledge Area, viewpoint, e-mail, Web page if any), please contact either: Robert.Dupuis@uqam.ca or Pierre.Bourque@uqam.ca All reviewers will be recognized by having their name on the list of contributors. ----------------------Review Captains-------------------------- The reviewers will be grouped by viewpoint within each Knowledge Area. These groups of 5-10 reviewers will be assigned a Review Captain who will be responsible for compiling the reviewer comments for the KA Specialist. The criteria for selecting Review Captains are: - Knowledge in the Area; - Availability; - Ability to synthesize various opinions. Schedule. The plan is that the Review Captains will be called upon to contribute during the June 18 and July 2, 1999, period. For further information or to submit candidate Review Captains (name, affiliation, Knowledge Area, viewpoint, e-mail, Web page if any), please contact either: Robert.Dupuis@uqam.ca or Pierre.Bourque@uqam.ca All Review Captains will be recognized by having their name on the list of contributors. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming Topics TBA: Clients, Students, and Projects Guest Editor: Susan A. Mengel Texas Tech University TBA: Software Process Improvement Education Editor: Donald J. Bagert Texas Tech University For more information about a particular issue's topic, please contact the corresponding guest editor. Please refer to the article format provided at the end of each issue when making submissions, which are always made directly to the guest editor. Here are some possible topics for future issues: * Accreditation * CASE Tools * Distance Learning * The Relationship Between SE and Other Disciplines If you are interested in being a guest editor for any of these topics, or have any suggestions for future topics, please contact me at bagert@ttu.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### From: "Dennis J. Frailey" Software Engineering Coordinating Committee Web Page The Software Engineering Coordinating Committee (SWECC), a joint committee of the ACM and the IEEE Computer Society, has prepared a Web page describing its activities and projects and providing links to other activities related to software engineering as a computing profession. The web page is available through the "public policy" section of the ACM web page and, in a mirrored fashion, from the IEEE-Computer Society web site. To go there directly, the ACM URL is: The (temporary?) Computer society URL is: ###################################################################### From: Dennis K. Peters Update on Lawsuit about use of the term "Software Engineering" ============================================================= Tensions in the ongoing dispute between the Association of Professional Engineers and Geoscientists of Newfoundland (APEGN) and Memorial University of Newfoundland (MUN) have been ratcheted up several notches in recent months. The dispute relates to the use of the name "Software Engineering" for an Honours B.Sc. programme offered by MUN's Faculty of Science through its Dept. of Computer Science. APEGN and the Canadian Council of Professional Engineers (CCPE) have filed a Statement of Claim alleging trademark violation since this program is not accreditable as an Engineering programme. In January, court ordered mediation talks aimed at resolving the dispute broke down, and the matter is scheduled to proceed to federal court in St. John's in September 1999. Meanwhile, in a move designed to 'encourage' an out of court settlement, APEGN has withdrawn its consent for accreditation evaluation of MUN's existing engineering programmes, effectively halting renewal of the accreditation. The current accreditation expires at the end of June. If not reinstated, students graduating in 2000 or thereafter will not be considered to have graduated from and accredited programme and will need to be assessed on a case by case basis for registration as professional engineering in Canada. APEGN has clearly stated that they do not have any concerns with quality of these programmes, which are offered by the Faculty of Engineering and Applied Science, however, they believe that they are acting in the public interest in trying to force MUN to stop using the term "engineering" to describe a non-engineering programme. MUN has filed papers with the Supreme Court of Newfoundland Trial Division seeking a judicial review to quash the decision by APEGN to withdraw its consent for the accreditation process. That matter should be before the courts in a matter of weeks. Some further information can be found in the Feb. 4 and March 4 issues of the MUN official newspaper, "The Gazette", http://www.mun.ca/univrel/gazette/1998-99/Feb.4/news/n01-cour.html http://www.mun.ca/univrel/gazette/1998-99/Mar.4/news/n02-tri.html ###################################################################### From: Mark Sebern Milwaukee School of Engineering Announces New Undergraduate SE Program The Electrical Engineering and Computer Science Department of the Milwaukee School of Engineering (Milwaukee, Wisconsin) has announced a new undergraduate program in software engineering. Program details are available on the web at: http://www.msoe.edu/eecs/se/ The new software engineering program incorporates an "application domain" elective sequence similar to that defined by the Rochester Institute of Technology and a large-scale software development laboratory inspired by the "Real World Lab" at the Georgia Institute of Technology. The software engineering program is accepting students for the 1999-2000 academic year, and we intend to pursue ABET accreditation as soon as we have graduates. The introduction of software engineering and the growth of our ABET-accredited computer engineering program have opened a number of faculty positions, for which we are actively recruiting (a faculty position announcement appears elsewhere in FASE). ###################################################################### From: David F. Rico Software Process Improvement (SPI) Webpages Please visit my new Software Process Improvement (SPI) Webpages: * http://members.wbs.net/homepages/d/a/v/davidfrico.html http://www.geocities.com/ResearchTriangle/System/4993/ http://davidfrico.webjump.com There are "many" free downloads, such as: * SPI: Impacting the Bottom Line by Using Powerful Solutions http://members.wbs.net/homepages/d/a/v/davidfrico/spibrief.pdf * A Synopsis of the Personal Software Process-SM (PSP)-SM http://members.wbs.net/homepages/d/a/v/davidfrico/psp.pdf Share my Webpages with your colleagues, thanks . . . (SM)PSP is a service mark of Carnegie Mellon University. (SM)Personal Software Process is a service mark of Carnegie Mellon University. ###################################################################### From: Don Bagert FASE-TALK Discussion Thread: Growth of SE Education I have recently started a discussion thread on FASE-TALK regarding the growth of software engineering education or (possibly) the lack of it. If you are interested in this discussion, you can subscribe to the FASE-TALK listserv by writing to and, in the text of your message (not the subject line), write: subscribe fase-talk ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Mike McCracken A Conference on Knowing and Learning to Design Georgia Institute of Technology April 27-28,1999. We invite you to participate in an important workshop on cognition and design education. Because of your recognized involvement in aspects of design and design education, we hope that you will be able to attend this important event. The conference consists of a set of invited papers which we anticipate will initiate a series of books to establish the framework for design learning for the future. In addition, we anticipate identifying a research agenda for the field, so that we may rejoin and invite others to continue the dialogue in 12 to 18 months. Please refer to our conference web site for more details on the conference. http://www.cc.gatech.edu/conferences/kld99 Registration information is included. Note that we have blocked a small number of rooms at a hotel near Georgia Tech. Refer to the conference on Design Knowing and Learning when making your reservations. The web site will have up-to-date hotel information. We hope to see you in April. Mike McCracken Wendy Newstetter Chuck Eastman ###################################################################### From: Sal Valenti CALL FOR PAPERS 3rd Annual IASTED International Conference on Software Engineering and Applications (SEA '99) October 6 - 8, 1999 Holiday Inn Sunspree Resort, Scottsdale, Arizona, USA Sponsor: International Association of Science and Technology for Development - IASTED Purpose: The 3rd International Conference on Software Engineering and Applications provides an international forum for presentation and discussion of research on software engineering and applications. The conference will feature contributed papers and tutorials concerned with theory, practice and applications Scope: The topics will include, but are not limited to, the following areas: Software Architecture OOA/OOD/OOP Object-Oriented Databases Objects, Components, Frameworks and UML Software Metrics and Models Software Process Improvement User Interface Design Technology Performance Engineering of Software Systems OO Software Testing and Reuse Real-Time Computing/Embedded Systems Visual Modelling Techniques Component-Based Software Engineering Intelligent Systems OO Software Requirements Engineering OO Rapid Prototyping Fault Tolerance and Software Reliability Formal Methods Networking and Distributed Computing Information System Architecture Visual and Multimedia Computing and Systems Use Case Modelling Software Quality Assurance Software Maintenance Software Reengineering/Reverse Engineering Information Engineering Software Configuration Management Concurrent/Network Programming Design Patterns /CORBA Data Warehousing and Mining Managing Evolution of Software Development Environmental Software Simulation Software Engineering Education and Training Performance Evaluation and Measurement International Program Committee: H. Abachi (Monash University, Australia) K. Akingbehin (University of Michigan, USA) N. Alexandridis (George Washington University, USA) F. Armour (George Mason University, USA) A. Behforooz (Towson University, USA) S. Chan (The Boeing Company, USA) C.-C. Chiang (Alabama A & M University, USA) C. Chiang (Viasoft Inc., USA) W.S. Cho (Chungbuk University, Korea) J. Choi (California State University, USA) V. Ciric (University of Belgrade, Yugoslavia) A. Chung (Depaul University, USA) H.K. Dai (Oklahoma State University, USA) W. Dosch (Medizinische University zu Lubeck, Germany) J. Dullea (The Boeing Company, USA) R. Dumke (University of Magdeburg, Germany) R. Fox (University of Texas, USA) A. Goal (Michigan Technological University, USA) W. Golubski (University of Siegen, Germany) J. Hammer (University of Florida, USA) J. Hanson (Ferris State University, USA) H. Hays (SE Missouri State University, USA) F. A. Henskens (University of Newcastle, Australia) B. Hillsburg (IBM, USA) N. Ishii (Nagoya Institute of Technology, Japan) T. Jones (Duquesne University, USA) J.T. Jung (Hansung University, Korea) D. Karolak (TRW Automotive Electronics, USA) B. Kasztenny (Texas A & M University, USA) H.G. Kim (Catholic University of Taegu Hyosung, Korea) J. H. Kim (Kangwon University, Korea) W.W. Kim (Kyungnam University, Korea) W. Lam (University of Hertfordshire, UK) J. Lee (University of Aizu, Japan) W. Leigh (University of Central Florida, USA) B. Lim (Illinois State University, USA) L. Lundberg (University of Karlstrona, Sweden) H. McAllister (University of Ulster, UK) J. Miller (University of Kansas, USA) N. Moon (Ewha Womans University, Korea) S. Oliveira (University of Iowa, USA) Y. Ouyang (California State University, USA) A. Parish (University of Alabama, USA) M. Picavet (University of Lille, France) S. Shin (South Dakota State University, USA) I.L. Song (Drexel University, USA) J. Tanaka (University of Tsukuba, Japan) A. Toptsis (York University, Canada) S. Tragoudas (University of Arizona, USA) R. Uzal (University Nacional de San Luis, Argentina) S. Valenti (University of Ancona, Italy) F.Y. Wang (University of Arizona, USA) S. Wu (California State University, USA) C. Xu (Georgia Southern University, USA) M. Yaacob (University of Malaya, Malaysia) K. Yun (University of California, USA) S. Zeadally (University of Southern California, USA) C. Zhang (California State University, USA) Submission of Papers: We solicit new research and 'real experience' papers in any of the technical areas listed above. Manuscripts must be in English, double spaced, 12 point font, and must not exceed 15 pages. The first page of the manuscript should include the article title, authors' name(s), affiliations, postal addresses, telephone and fax numbers, and e-mail address of the principal author. The second page should begin with the article title, a brief abstract, key words and the text. Papers will be peer-reviewed. Four copies of the full paper should reach the Program Chair on or before May 5, 1999 at the following address. (Please e-mail the Program Chair to let him know that your paper has been mailed and you will present the paper if the paper is accepted.): Professor Roger Y. Lee Computer Science Department Central Michigan University Mt. Pleasant, MI 48859 USA Telephone: 517-774-3811 Fax: 517-774-6938/3728 E-mail: lee@cps.cmich.edu Cooperation with IJCA: Authors of selected papers will be invited to submit an extended version for possible publication in the International Journal of Computers and Applications published by ACTA Press and sponsored by IASTED. Submission of Tutorials: We invite you to submit half-day (3 hour) proposals for technical tutorials. A proposal should include the title, instructor's name, topics covered, length (hours) of the tutorial, targeted audience, equipment needed, number of participants, and instructor's biography and qualifications. It should also indicate the objectives and the time allocation for major course topics. There is a small fee for tutorial attendees. Submit four (4) copies of your 2-page proposal to the Tutorial Chair on or before May 5, 1999: Professor Sung Y. Shin Computer Science Department South Dakota State University Brookings, SD 57007 USA Telephone: 605-688-6235 Fax: 605-688-5822 E-mail: shins@mg.sdstate.edu Steering Committee: Dr. Narayan C. Debnath (Winona State University) Dr. Dale Karolak (TRW Automotive Electronics) Dr. Roger Y. Lee (Central Michigan University) Dr. William E. Leigh (University of Central Florida) Dr. Sung Y. Shin (South Dakota State University) Dr. James Tomayko (Carnegie Melon University) Dr. Lynn Andrea Stein (Massachusetts Institute of Technology) General Chair: Narayan C. Debnath Winona State University Phone: (507) 457-5261 E-mail: debnath@vax2.winona.msus.edu IMPORTANT DEADLINES: Papers and Tutorials Due: May 5, 1999 Notification of Acceptance: June 25, 1999 Camera-Ready Manuscripts and Registrations: August 10, 1999 For more information, or to be placed on the mailing list, please contact: IASTED Secretariat - SEA'99 1811 West Katella Avenue, Suite 101 Anaheim, CA USA 92804 Tel: 714-778-3230 or 1-800-995-2161 Fax: 714-778-5463 Email: iasted@iasted.com SEA'99 Web Site: Go to http://www.iasted.com and follow the link to SEA'99 on the list of current conferences ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Mark Sebern Milwaukee School of Engineering Software Engineering Faculty Computer Engineering Faculty The Electrical Engineering and Computer Science Department of the Milwaukee School of Engineering invites applications for faculty positions in its computer engineering and software engineering programs. A doctorate in computer engineering, computer science, or electrical engineering is required, as is significant experience in engineering practice. At MSOE, faculty members are judged primarily on excellence in teaching. Applied research and interaction with industry partners are also encouraged. Please send a resume and the names of three references to: Faculty Search Committee EECS Department Milwaukee School of Engineering 1025 N. Broadway Milwaukee, WI 53202-3109 Further information is available on the web at: http://www.msoe.edu/eecs/ce/ http://www.msoe.edu/eecs/se/ Founded in 1903, MSOE is a private, application-oriented university with programs in engineering, business, and nursing. MSOE provides its graduates with a strong foundation in theory and practice, achieving a 99 percent placement rate. MSOE's 12+ acre campus is located near Milwaukee's East Town, Theater District, and Lake Michigan. MSOE's new undergraduate software engineering program is accepting students for the 1999-2000 academic year, and we intend to pursue ABET accreditation as soon as we have graduates. Our ABET-accredited computer engineering program continues to grow in popularity. Openings exist for candidates with expertise in a variety of areas, across the spectrum of computer and software engineering. The Milwaukee School of Engineering employs a retention and promotion system based on long-term renewable contracts; there has been widespread interest in this system, as presented at the American Society for Engineering Education national conference and described in ASEE Prism. Candidates should understand that we are seeking faculty who wish to make a continuing contribution in the areas of teaching and applied research, and that these are intended to be "career" positions. ###################################################################### From: Armin Eberlein (Please pass on this information to interested students!) University of Calgary Department of Electrical & Computer Engineering Applications are invited for a M.Sc./Ph.D. studentship in Requirements Engineering in the Department of Electrical&Computer Engineering of the University of Calgary. The program will start on September 1st, 1999. The ideal candidate will have outstanding academic records, demonstrated research experience and a background in software and requirements engineering. If the successful student has already a Master's degree from outside Canada he/she may be admitted to the M.Sc. program initially and considered for transfer to the Ph.D. program in 8 to 12 months. Conditions for transfer are satisfactory performance in courses and sufficient progress in research to demonstrate the potential for successfully completing a Ph.D. research project. Credit is given for all courses taken and there should be no delay as a result of having to register in the M.Sc. program initially. The studentship will be around $16,000/year. International students are encouraged to apply. For more information, please contact Dr. Armin Eberlein (eberlein@enel.ucalgary.ca). The departmental deadline for formal applications is April 9th, 1999. Dr. Armin Eberlein Assistant Professor Department of Electrical & Computer Engineering University of Calgary Tel: +1 (403) 220-5002 2500 University Drive NW Fax: +1 (403) 282-6855 Calgary, AB, Canada T2N 1N4 e-mail: eberlein@enel.ucalgary.ca http://www.enel.ucalgary.ca/People/eberlein ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 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: bagert@ttu.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: Kathy.Beckman@cdsi.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