Forum for Advancing Software engineering Education Volume 7 Number 02 - September 15, 1997 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents: Letter from the Co-Editor This month's topic: Undergraduate Software Engineering Upcoming topics News Items Survey on Software Engineering Web Page David Parnas has CACM Column on Software Engineering Survey on CSEE&T An NSF-CISE Educational Infrastructure Workshop Questions on Training Plagiarism Discussion Thread in SIGCSE.members CFP: B'98 Humor: Software Engineering Glossary From A Marketing View Countries with Subscribers to FASE Contact and General Information about FASE +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Don Bagert Letter from the Co-Editor On behalf of the FASE staff, let me welcome you the second issue of the "New FASE". First of all, I left out an important note in the last issue: that is, to give a very warm "Thank You" to Keith Pierce for his six years of hard work on FASE. Without Keith, this newsletter would probably not exist today. I hope things are going well in industry, Keith! This month, we start our monthly discussion topic. This month's topic is undergraduate computer science education and curricula. In light of recent events, we think that this is a timely topic, and hope you agree. Let us know what you think! Following this month's discussion, some information about future topics is available. Once again, we'd like to get your thoughts and involvement. FASE will continue to evolve over the next several months, but it will also continue to be a place for dissemination of information and wide variety of ideas, currently labeled as "News Items". Please feel free to send your thoughts, CFPs, and other items that you feel would be of interest to the FASE readership. One of new sections that will be added in future months will be devoted to your letter of comment (LOCs). Information on how to send LOCs is included at the end of this issue. The FASE and FASE-TALK listservs are still pending the receipt of an activation key. When it arrives and is installed (probably later this week), I will send out an announcement to FASE subscribers. Finally, the new FASE web page can be found at http://www.cs.ttu.edu/fase It is still mostly in the construction stage, but will eventually allow for the current issue to be available in HTML format, and provide a repository for back issues. As always, thanks for your time, attention, and support of FASE. Don Bagert P.S. You will note that in this document there are entire lines that contain a single symbol. Lines entirely consisting of + signs (like the one immediately below this paragraph) are breaks for major sections (such as the monthly topic), while lines consisting of # signs separate out subsections (such as two different opinions within the monthly topic discussion). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introduction By: Don Bagert This month's topic: Undergraduate Software Engineering We invited several leaders in the field of software engineering education to participate in a forum on the topic of "Undergraduate Software Engineering Education and Curricula". We asked them the following question: "What are your predictions and recommendations concerning the future of undergraduate software engineering education and curricula?" The panel were told that their response could be in any length from a paragraph to a couple of pages, depending on their time constraints, and whatever they felt was appropriate. The following are our respondents: James H. Cross II (cross@eng.auburn.edu) is the chair of the Department of Computer Science and Engineering at Auburn University. His research interests include reverse engineering and Ada-based educational software tools (including GRASP, which has been extended for additional use in C and Java). Peter J. Knoke (ffpjk@aurora.alaska.edu) is an Associate Professor of Computer Science a the University of Alaska - Fairbanks. He is a member of the Working Group on Software Engineering Education. Nancy Mead (nrm@sei.cmu.edu) is Senior Member of the Technical Staff in the Community Sector of the Software Engineering Institute. She is currently involved in the development of professional infrastructure for software engineers. Among her specific projects in the leadership of the Working Group on Software Engineering Education, and membership on the FASE Advisory Board. Raman Kannan (kannan@moncol.monmouth.edu) is an Assistant Professor in the Software Engineering Department at Monmouth University. He is also a member of the Working Group on Software Engineering Education. Don Bagert is an Associate Professor of Computer Science at Texas Tech University. We thank our panel for their comments below, and, as always, invite letters of comment. ################################################################# Comments From: James H. Cross II (cross@eng.auburn.edu) The future of undergraduate software engineering (SE) education and curricula will depend to a large extent on the following. (1) The maturity and acceptance of a well-defined body of knowledge. There has been progress made in this area, but we still have a long way to go. Part of the problem is the lack of a clear understanding of the difference between computer science and software engineering. The chemistry folks and chemical engineering folks seem to understand this difference. The CS/SE distinction strikes me as being much more blurred. Although many departments offer one or more upper level software engineering courses in their computer science or computer engineering curricula, software engineering principles should be taught beginning with the first programming course. (2) The perception of software engineering as a engineering discipline by other engineers. This cannot be underestimated. Organizations like the IEEE Computer Society, which is perhaps more engineering-oriented than the ACM, must become major proponents. (3) Colleges of engineering vs. non-engineering colleges. Whether the department offering the software engineering curriculum is in a college of engineering may have an impact the overall success and acceptance of software engineering as a discipline. In addition, the legal aspects of term "engineer" must be considered. ################################################################# Comments From: Peter J. Knoke (ffpjk@aurora.alaska.edu) On Undergraduate SE Education Pete Knoke Univ of Alaska Fairbanks 7 Sep 97 -------- In this piece, I present some personal views on undergraduate SE education. The intent is to stimulate discussion, especially in the light of increased interest in SE professionalism recently. I know that the idea of a SE undergraduate program separate from CS undergraduate programs was vigorously discussed in forums such as the Communications of the ACM a few years ago. There seemed to be a consensus then that a separate undergraduate SE degree would be undesirable, splintering an already small CS field while providing few benefits. However, Rochester Institute of Technology has taken the lead by establishing an undergraduate SE program. I believe that others will soon follow because there is a market in industry for graduates of such programs. Further, I believe that most near-future undergraduate SE programs will evolve from existing undergraduate CS programs, because: 1) the overlap between a typical present undergraduate CS program and a desirable undergraduate SE program is considerable; 2) resource constraints (faculty and money) at most universities make a separate brand-new SE program infeasible in many university environments 3) the inherent conservatism of most academic environments and their denizens makes most other alternatives unlikely even if (2) above were untrue. Thus, the most likely near-future undergraduate SE programs will come from grafting new SE modules onto a collection of surgically altered CS program modules. The surgery will have the effect of downsizing some modules and deleting others. Downsizing might correct problems describable as "too much of a good thing" (e.g., analysis of algorithms, automata theory, and complexity theory). Complete deletions of modules will depend on the specific programs, and will certainly cause screams of pain and outrage from proponents of such modules. In the interest of near-term feasibility, downsizing is preferable to deletion. Even the downsizing should be gradual for political reasons. The need for downsizing/deletion arises from the impossibility of putting 10 pounds of material in a 5 pound bag (or putting all the old CS modules plus the new SE modules into a 120 or 130 credit-hour undergraduate curriculum). The required new SE modules will vary from one host CS program to another. Some typical SE deficiencies of CS undergraduates at my school (with a CSAB accredited BSCS program) are as follows: * Computer system engineering knowledge & skills (hardware/software trades, allocations of functional and performance requirements to hardware and software) are minimal. * Systems engineering knowledge & skills (both practical and theoretical) are minimal. * Software requirements engineering knowledge & skills are minimal. * Software design knowledge & skills, and knowledge of and skills in software design tradeoffs, is minimal (some CS students don't know the difference between design and coding, and have no idea of the meaning of "tradeoff"). * Software test knowledge & skills (test plans, strategies and techniques, black box and white box testing) are minimal. * Software process knowledge & skills(CMM, PSP, etc.) are minimal. * Software project management knowledge & skills (PERT and Gantt charts, software metrics, etc.) are minimal. * Software quality and quality control knowledge & skills are minimal. * Knowledge of software standards and understanding of their importance is minimal. * Knowledge of SE professional matters (ethics codes, intellectual property law, etc) is minimal. I try to cover some of the above in a required senior level "real" team projects course. More is covered in an elective senior-level generic software engineering course. Both courses address skills issues with hands-on projects. Also, I insert appropriate SE modules and tidbits into other courses that I teach regularly (e.g., computer networks, computer architecture, AI, and programming). The results from these efforts are probably better than nothing, but far from sufficient from an SE industry requirements point of view. Over time, software modules correcting more of the above kinds of SE deficiencies might be added to undergraduate CS curriculum at my school. Possibly, a separate undergraduate CS track with more SE emphasis will appear eventually. However, faster and more aggressive change in the SE direction needs pressures from above in the academic hierarchy (e.g., Dr. Hirmanpour of Embry-Riddle University has advocated and supported PSP introduction and experimentation in low-level programming classes at that school). I suspect such cases may be rare, however. So, there are some thoughts. Comments, opinions, and disagreements are welcome. Pete Knoke ################################################################# Comments From: Nancy Mead (nrm@sei.cmu.edu) Undergraduate Software Engineering : What lies ahead? Nancy Mead, SEI (This is my personal view, not a position that had been reviewed or endorsed by the SEI) As a manager at IBM hiring new programmers, I used to look for programmers who had the infamous software project course. Since our applications were mission-critical real-time systems, I would also look for background in math, physics, and electrical engineering. The vast majority of the new hires were new college graduates. On occasion, we would get master's degree students who had some combination of degrees, such as a bachelor's in engineering and a master's in computer science. These days, we are seeing an evolution towards undergraduate degrees in software engineering. It is not taking place in the way that one might have hoped. Universities are not rushing to grant degrees in software engineering. Industry continues to make do with whatever it can get. Accreditation boards are not anxious to take on the problem of accrediting software engineering degree programs. Nevertheless, we have started to take some baby steps in undergraduate software engineering, and I think it will continue. We are seeing a few universities, notably RIT, stepping up to offer degree programs in software engineering. Meantime, the ACM/IEEE Steering Committee seems content to drag its feet and engage in political infighting over whether such degrees are needed. In industry, we would have asked if they wanted to be part of the solution or part of the problem. Undergraduate degree programs in software engineering will happen. The only question is whether the professional societies will step up to become a part of it, or if they will find themselves outmoded and outdated. Some argue that software engineering is a masters' level discipline. Unfortunately, the majority of software engineers do not get advanced degrees, so this line of thinking is inadequate. It may be that we will see undergraduate degrees in specific domains, for example, avionics software engineering. All this remains to be seen. The fact is, however, that it is unacceptable to refuse to teach people the methods that will be needed for their entire careers, in favor of teaching them things that the majority of software engineers will never encounter. We do not need very many software engineers who know how to develop operating systems, compilers, and database packages. We do need software engineers who know how to develop applications in a variety of application domains, from automotive to washing machines. ################################################################# Comments From: Raman Kannan (kannan@moncol.monmouth.edu) (Dr. Kannan wishes to mention that these comments are his, and not necessarily the views of Monmouth University.) Undergraduate Education in Software Engineering: Who, What, When and How? Any problem solving activity can be approached asking the fundamental questions: (1) Who will or should do it? (2) What should be done? (3) When should be done? and (4) How should it be done? The Software Engineering Education community might serve itself by asking the same questions regarding UG SE Education. This is our short random musing or core dump at this time. In other words this is not our final thought on the subject matter but an evolving one. The question in our minds has never been one of "should we offer SE at the UG level at all or not?" - Rather one along the dimensions presented above. Times have changed dramatically over the last 10 years regarding SE education. There is broad based acceptance of the discipline at the graduate level. Thanks to the efforts of die hards like Parnas, Nancy Mead (SEI) to name a few. But there is my dilemma and food for thought? Have we learned anything from our experience in offering SE at the graduate level? Do we know if there has been an impact in the profession? What do our graduate SE do in their work place? Are they fighting loosing battles on planning first, configuration management, documentation and standards? In other words we must first find out how effective have we been in educating and training mature software engineers at the graduate level. It is our belief that SE mindset will not take hold until such SE graduates percolate to the upper echleons of the corporate houses or the SE mindset and awareness percolates into the current upper echleons. Otherwise, our graduates will fight a few battles and soon however reluctantly will join the crowd into mindless java programmers, pattern hatchers and the like. Put it in production now and fix it later and for ever while in use. Blame everything else (technology, education) but the root cause the lack of discipline and engineering mindset. More fundamentally, we also posit that the modus operandi of graduate level education at the UG level are much different then in the PG level. Especially due to accreditation and other standardization and quality control processes. What should it be? What should our objectives be? I believe the SE UG should be much like the medicine. Without residency our graduates will remain ready with paper theories and no practical insight. Much less resistance to the prevailing corporate SE abyss and will join (inevitably) the crowd just like the SE PG but a lot sooner. Doctors may not practice until their residency. So must our future SE UG. In closing, we certainly have not much offered in the way of details and specifics. Because such would be premature. Undeniably one more attempt by education industry for increasing or sustaining current levels of enrollment. We initiate a debate in this forum that: (1) Non-Degree SE Awareness Education for corporate upper echleon in a massive scale; and (2) UG offering with residency. Now let us ponder these issues in substance. Non-Degree SE Awareness Education for Corporate Upper Echleon Why should they pursue such an learning endeavor? Can we expect them to accept "grading" as we know it? Perhaps not! Does time constraints (semester, quarterly) mean anything to them? How does it matter if someone attains proficiency in configuration management in three months or 12 months? What does it mean to stamp a vice president as B grade student. Well the employee does not think so otherwise they would not be vice president. Furthermore such grading will leave an undelible mark in their track record. Grades must go for these category of learners! That is our opinion but the focus of this thought is that "What is our charter? Will grading help?" Residency for Software Engineers Without cooperative and willing hospitals such is not possible. So also SE residency will not fly without the support from corporations that are in the business of software. It is not so simple as it involves quite a few issues. There is government incentive for such hospitals. What about incentives for such SE residency corporations. Will traditional summer intern programs suffice? Definitely not, in our opinion. Most importantly, what is in it for students to undertake two more years of less compensation when they can learn to hack java tonight and make a decent living. Will employers seek out resident software engineers? Back to square one. Upper echleons (hiring managers) must appreciate the significance and return on investment again. So we part with this request to the FASE community? What do you think? Are these important issues? Or should we debate what we teach in a Design course at this time? ################################################################# Comments From: Don Bagert (bagert@ttu.edu) A Possible Software Engineering Undergraduate Curriculum I'll try to be brief. I am going from the point-of-view that accredited undergraduate software engineering education in the U.S. is inevitable. The only question is when. I think that it will happen in 2001-02 when RIT's program is scheduled for ABET review. At Texas Tech, we currently have a Software Engineering Track in our graduate program, which we want to expand to a full- fledged Master's program within the next 2-3 years. Eventually, it is expected that B.S. and Ph.D. degrees will also be offered in software engineering. In March, 1995, Michael Lutz and his colleagues at the Rochester Institute of Technology (RIT) released a document entitled "A Proposed Undergraduate Program in Software Engineering" for peer review and comment. This paper has been a great motivating factor for me. It reflected some of my own feelings on the subject of a software engineering B.S. curriculum, while crystalizing others. In particular, it has led me to visualize what the B.S. program might look like at Texas Tech University. First of all, Texas Tech is on the semester system, and computer science is in the College of Engineering. There is no Computer Engineering program yet (instead having a very successful EE/CS dual degree), although one is in the works. In the breakdown below, one of "computer engineering" courses reside in EE and one in CS. It is also believed that the Texas state legislature will soon limit undergraduate degree programs to 120 hours. Therefore, this proposed curriculum does the same. (I should also mention that I am not an expert on ABET 2000 guidelines, so I am not claiming that this curriculum will conform to it.) Subject/Area # of semester hours Software Engineering 27 Computer Science 21 Computer Engineering 6 Electrical Engineering 3 Mathematics 18 Physical Science 12 Technical Writing 3 General Education Requirements 30 ----------------------------------------- Total 120 semester hours Below is a breakdown of each area. Each course is three semester hours of credit, unless otherwise indicated. The course names shown below are not necessarily the actual exact titles. Software Engineering Software Engineering Seminar I - 1 hour Software Engineering Seminar II - 1 hour Fundamentals of Software Engineering - 4 hours Software Development Methodologies Software Process and Process Improvement Software Project Management Software Metrics Senior Project I Senior Project II Software Engineering elective, choose one of: Software Engineering Formal Methods Real-Time and Concurrent Software Systems Human-Computer Interaction Computer Science Fundamentals of Computer Science I (CS1) - 4 hours Fundamentals of Computer Science II (CS2) - 4 hours Discrete Structures Design and Analysis of Algorithms Concepts of Programming Languages - 4 hours Operating Systems Computer Engineering Digital Logic Computer Organization and Assembly Languages Electrical Engineering Introduction to Circuit Theory Mathematics Calculus I, II, and III Linear Algebra Differential Equations Probability and Statistics Physical Sciences Physics I and II Chemistry I Technical Writing - one course General Education Requirements English I and II U.S. History I and II U.S. and Texas Government Business and Professional Communication Humanities electives - 6 hours Individual/Group Behavior elective - 3 hours Should there be more software engineering courses? Probably, but this is what I think that the program will look like when it is first started, hopefully in about five years. Anyway, that's a first cut, and comments are of course welcome. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert Upcoming topics The topic for the October issue of FASE will be Industry/University Collaborations. Please send any suggestions or contributions to Kathy Beckman (Kathy.Beckman@cdsi.com) Distance learning will be the topic for the January 1998 issue. Sheneui Sloan of UC-Long Beach will be the guest editor. The November and December 1997 topics are yet to be determined, as the are the subjects for February 1998 and beyond. Please send any suggestions to Don Bagert at bagert@ttu.edu. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NEWS ITEMS ################################################################# From: Maria Letizia Jaccheri Forwarded by: Laurie Werth Survey on Software Engineering Web Page Dear all, in the context of a survey on software engineering education project, we have developed a web page to collect information and to publish our results. The page is http://www.polito.it/~chiarett/IREnglish.htm. We would very much appreciate if you could provide us with some feedback about the page and/or you could fill the form with information regarding your activities. I am sure this page has to improve and it would benefit from your comments. Regards and thanks Letizia Maria Letizia Jaccheri DAI Politecnico di Torino Corso Duca degli Abruzzi 24 I-10129 Torino tel: +39-11-5647079 fax: +39-11-5647099 e-mail: letizia@polito.it ################################################################# David Parnas has CACM Column on Software Engineering By: Don Bagert Thanks to: Nancy Mead for bringing this to our attention. David Lorge Parnas, Professor in the Department of Electrical and Computer Engineering at McMaster University in Ontario, Canada, and internationally-known authority on software system design, provided a column entitled "Software Engineering: An Unconsummated Marriage" on page 128 of the September 1997 issue of Communications of the ACM (CACM). The "unconsummated marriage" in the title of Dr. Parnas' column refers to that of the computing and engineering fields in regards to software engineering. Parnas states that "...communication between engineers and those who study software hasn't been effective. The majority of engineers understand very little about the science of programming or the mathematics that one uses to analyze a program, and most computer scientists don't understand what it means to be an engineer... "Software engineering is often treated as a branch of computer science. This is akin to regarding chemical engineering as a branch of chemistry. We need both chemists and chemical engineers but they are very different. Chemists are scientists; chemical engineers are engineers. Software engineering and computer science have the same relationship. "The marriage will be successful only if the engineering societies, and computer scientists come to understand that neither can create a software engineering profession without the other. Engineers must accept that they don't know enough computer science. Computer scientists must recognize that being an engineer is different from being a scientist, and software engineers require an education very different from their own." [Editor's note: Dr. Parnas provided similar comments, in an expanded format, in a keynote speech at the Conference on Software Engineering Education and Training (CSEE&T) last April.] ################################################################# From: Nancy Mead Survey on CSEE&T Dear Colleague: The Steering Committee of the Conference on Software Engineering Education and Training would like your input on how well the conference meets your needs, so that we can factor it into our long-term planning (beyond 1998). "The CSEE&T purpose is to influence directions in education and training, to stimulate new instructional approaches, to promote collaboration, and to generate exchanges among software engineering stakeholders. Software engineering cannot stand in isolation: To be a vibrant, evolving discipline, bridges must be built and maintained to a variety of other disciplines and organizations. The development of curricula and training programs can only be enhanced by close working relationships with computer science and established branches of engineering. In addition, industrial and academic collaboration is essential to the creation of educational and training programs that can adapt to evolving needs and advancing technology. Educators and trainers have a key role to play in creating and sustaining these critical bridges. The goal of this conference is to explore the nature of these relationships, and the means we have to ensure fruitful, professional interactions." Thank you for taking the time to answer these questions. We value your input and appreciate your feedback. Please return to Charlene Svitek at crs@sei.cmu.edu by October 15. 1) To meet the objectives, I prefer to: a. continue the conference b. conduct workshops instead c. neither 2) Should the conference be held: a. annually b. every other year 3) Should the conference be: a. back-to-back with SIGCSE b. back-to-back with other technical conferences c. stand alone 4) I attend the conference: a. regularly b. occasionally c. have never attended 5) At the conference, I get the most out of: (prioritize these with 1=most benefit and 6=least benefit) a. tutorials b. keynote talks c. workshops d. papers and panels e. Birds of a Feather f. social events 6) The conference depends on voluntary participation. For the conference, I am willing to: (check all that apply) a. be a referee b. be on the committee c. be a chair d. author papers/panels/proposals e. attend 7) The biggest barrier for attending the conference is: a. no time b. no travel money c. not enough new information/poor content d. other 8) I prefer workshops that are: a. 1-2 days attached to other conferences such as ICSE b. stand-alone 1-2 days c. 1 week intensive workshop with products (such as was conducted at The Evergreen State College in 1997) 9) Topics that I would like to see in a workshop are: -------------------------------------------------------------- -------------------------------------------------------------- -------------------------------------------------------------- 10) Workshops also need voluntary participation. For a workshop I am willing to: (check all that apply) a. recruit speakers b. be a host location/chair c. be on the committee d. help facilitate 11) Instead of either conferences or workshops, I would prefer the following: -------------------------------------------------------------- -------------------------------------------------------------- -------------------------------------------------------------- ################################################################# From: Nancy Mead (via Torleiv Flatebo Ringer) An NSF-CISE Educational Infrastructure Workshop This webpage has the results of a workshop that I was involved in this summer. Check it out! ------- Forwarded Message Hello everyone! I have a new edition of our website up and running at: www.evergreen.edu/user/CISE [Editor's note: The title of the workshop was "Integrating Recent Research Results", and had a major software engineering component.] If everyone could check it out and let me know what you think(feedback is very important to me!) I would greatly appreciate it. If you have any questions comments or concerns, please e-mail me at ringert@elwha.evergreen.edu Torleiv Flatebo Ringer ------- End of Forwarded Message ################################################################# From: Eric Blomberg via Nancy Mead Questions on Training Professor Mead, I appreciated your Best Training Practices paper...Data for which I am searching is close to the focus of your paper. I would be grateful if you could point to people or groups I might ask. My concern is effectiveness (ROI) of training for technology introduction in the Electronic Product Hardware Design Area (Intel, Dell, Sony, Sun...). We are trying to quantify ROI for three approaches: 1) provide design tools (software) 2) provide tools + SW use training 3) provide tools + hands-on, co-pilot, application engineer support while executing an actual project 4) # 3 AND SW use training Thanks, Eric Blomberg Cadence Design Systems ericb@cadence.com ################################################################# From: Robert B. France CFP: B'98 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% %% %% B'98 %% %% %% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Call for Papers The 2nd International B Conference Montpellier, France April 22-24 1998 URL: http://www-lsr.imag.fr/B98/ Organized by the B Conference Steering Committee (APCB) Supported by the Z User Group (ZUG), the B User Group (BUG) and the LIRM, University of Montpellier, France Aims and Scope: --------------- Following the success of the First B Conference which was held in Nantes in November 1996, the users of B have expressed their interest in a second conference. This conference aims to provide a forum for the rapidly growing community working in specification and software construction with the B method. The scope of the conference covers all aspects related to the B technology. Topics of interest include (but are not limited to): - Industrial applications and case studies using B; - Integration of the B method in the software development lifecycle (technical as well as economical aspects); - Software testing versus proof-oriented development; - Theoretical issues about the proof process and proof validation; - Support tools for the B method; - B and other specification languages; - Proposals for B extensions. Important dates: ---------------- Deadline for paper submission: October 13, 1997 Notification of acceptance: December 17, 1997 Camera-ready version due: January 26, 1998 Conference dates: April 22-24, 1998 Submission: ----------- Authors are invited to submit full papers for the conference. Submissions must not exceed 15 pages in the LNCS format. The cover page must clearly identify the author's name, address, phone, fax number and electronic address and a 150 word abstract. Papers should be sent by electronic mail or by surface mail (5 hard copies) to the programme chair: Didier Bert E-mail: B98@imag.fr LSR-IMAG, BP 72 38402 Saint-Martin-d'Heres CEDEX France Submitted papers must present original work and must not be simultaneously under review for any other conference nor submitted to a journal. They must be written in english. The organizators intend to publish the proceedings in the Springer- Verlag collection of Lecture Notes in Computer Science. Authors are invited to use the LaTeX LNCS style from the beginning. Details about the right style for typing papers are given below in the section "Instructions for the authors". Programme Committee: -------------------- Didier Bert, chair CNRS, LSR-IMAG, Grenoble, F Pierre Bieber ONERA-CERT, Toulouse, F Egon Boerger Univ. of Pisa, I Claude Boksenbaum Univ. of Montpellier, F Jonathan Bowen ZUG, Univ. of Reading, UK Pierre Desforges RATP, Paris, F Ranan Fraer Intel, Israel Robert B. France Florida Atlantic Univ., FL, USA Marc Frappier Univ. de Sherbrooke, Canada Philipp A. Heuberger TUCS, Abo Akademi Univ., Turku, Finland David Lightfoot Univ. of Oxford Brookes, UK Fernando Mejia GEC-Alsthom, Paris, F Ken Robinson Univ. of South Wales, Australia Pierre-Yves Schobbens Univ. of Namur, B Educational issues session: -------------------------- A session devoted to educational experience and issues is planned as satellite meeting of the conference. To get more information, contact: Steve E. Dunne E-mail: S.E.Dunne@tees.ac.uk Henri Habrias E-mail: Henri.Habrias@irin.univ-nantes.fr Location: --------- The conference will take place in Montpellier, a city in the south of France, close to the Mediterranean Sea. It is organized by the LIRM, the department of Computer Science of the University of Montpellier. Local organization chair: Claude Boksenbaum E-mail: boks@lirmm.fr LIRMM 161, rue Ada F-34392 Montpellier Cedex 5 France Instructions for the authors ---------------------------- All the instructions to get LaTeX and TeX styles of the llncs format can be found in the file "printing.txt" at the ftp address (login name: anonymous): ftp://ftp.imag.fr/pub/SCOP/Springer/ ################################################################# By: Don Bagert Noted as FASE-worthy by: Peter J. Knoke Plagarism Discussion Thread in SIGCSE.members The SIGCSE.members listserv has been having a lively discussion concerning plagiarism in programming assignments. This is an issue that has many sides, and has gone on for several days now. One other recent discussion involving sophomore-level software design courses. SIGCSE is the ACM Special Interest Group on Computer Science Education. If you are interested in subscribing to the SIGCSE.members listserv, send an email to listserv@acm.org with the message subscribe sigcse-members in the body of the text. There is no charge for being on this listserv, and, as far as I know, you do not have to be a SIGCSE member to join the list. ################################################################# From: Mark "Yue" Xu via Pete Knoke Software Engineering Glossary From A Marketing View (or, defining computer terms from a ="marketing point of view") * ALL NEW -- The software is not compatible with previous versions. * ADVANCED DESIGN -- Upper management doesn't understand it. * BREAKTHROUGH -- It nearly booted on the first try. * NEW -- It comes in different colors from the previous version. * DESIGN SIMPLICITY -- It was developed on a shoe-string budget. * EXCLUSIVE -- We're the only ones who have the documentation. * FIELD TESTED -- Manufacturing doesn't have a test system. * FOOLPROOF OPERATION -- All parameters are hard coded. * FUTURISTIC -- It only runs on the next-generation supercomputer. * HIGH ACCURACY -- All the directories compare. * IT'S HERE AT LAST -- We've released a 26-week project in 48 weeks. * MAINTENANCE FREE -- It's impossible to fix. * MEETS QUALITY STANDARDS -- It compiles without errors. * OPEN SYSTEMS -- Anything with our logo on it * PERFORMANCE PROVEN -- It works through beta test. * REVOLUTIONARY -- The disk drives go round and round. * SATISFACTION GUARANTEED -- We'll send you another copy if it fails. * STOCK ITEM -- We shipped it once before, and we can do it again, probably. * UNMATCHED -- It's almost as good as the competition. * UNPRECEDENTED PERFORMANCE -- Nothing ever ran this slow before. * YEARS OF DEVELOPMENT -- We finally got one to work. ################################################################# From: Don Bagert Countries with Subscribers to FASE There are currently there are 650 people from 40 countries that are subscribing to FASE. Using domain codes, these are the countries and provinces that have subscribers: Argentina Australia Austria Bahrain Belgium Brazil Brunei Darussalam Bulgaria Canada China Denmark Finland France Germany Greece Hong Kong Hungary India Indonesia Ireland Israel Italy Japan Korea, South Lithuania Macau Madagascar Malaysia Netherlands New Zealand Norway Poland Slovak Republic Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Ukraine United Kingdom United States Yugoslavia (Editor's note: Yes, I realize the various relationships that the People's Republic of China has with Macau, Hong Kong, and Taiwan. No international incidents, please =) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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, Kathy.Beckman@cdsi.com; Academic education, and all other categories to Don Bagert, bagert@ttu.edu. Items must be submitted by the 8th of the month in order to be considered for inclusion in that month's issue. Send requests for information or to add, delete, or modify a subscription to bagert@ttu.edu. Send problem reports, returned mail, or other correspondence about this newsletter to bagert@ttu.edu. There is no cost for subscribing to FASE. Send requests for information problem reports, returned mail, or other correspondence about this newsletter to fase-request@cpm211-1.cs.ttu.edu. If it is a LOC (letter of comment) that can be included as such in a future issue of FASE, please put "letter of comment" (without the quotes) as the subject. The FASE Staff: Don Bagert -- Academic/Misc Editor and ListMaster 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