Forum for Advancing Software engineering Education (FASE) Volume 8 Number 04 (99th Issue) - April 15, 1998 812 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Letter from the Academic Editor This Month's Topic: Software-Related Law Next Month's Topic: 100th Issue - FASE: Past and Future Upcoming Topics Departments FASE Archive: Back Issues Located; Complete Set Now Available FASE Formatting: Feedback More Positive Curriculum Resources News Items Texas Board of Professional Engineers - Update A Further Summary of Events in Atlanta 21 Feb - 1 Mar 1998 Working Group for SEE&T Minutes Calls for Participation ECOOP'98 Workshop on Learning and Teaching Objects Successfully ICSE 99 PSP(SM) Summer Workshop for Faculty Faculty Positions University of Maryland University College Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert Letter from the Academic Editor Well, not much to say this month (hey - stop that cheering! =) except to thank Pete Knoke for the great job that he did with this issue's topic (software-related law) on relatively short notice. See you next month for our 100th issue extravaganza! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Pete Knoke, Guest Editor This Month's Topic: Software-Related Law GUEST EDITOR: PETE KNOKE (CS Prof, UAF) CONTENTS 1) Preface (Pete Knoke) 2) A Course in Computer Law (David Kay) 3) IPL Top 5 (Anonymous) 4) The Legal Standard of Professionalism (Jeff McAllister) 5) Some Recommended Sources (Pete Knoke) ###################################################################### 1) Preface Pete Knoke Assoc Prof of Computer Science University of Alaska Fairbanks ffpjk@aurora.alaska.edu "Software-related law" (or "computer law", or "technology law") is a subject of increasing importance and relevance for today's software engineers. This small set of items on that subject was intended to be of interest to the FASE audience and to convey a little of the flavor and scope of this burgeoning field. I believe the point has been reached where today's software engineer needs to have some awareness of software-related law. This is partly because such an awareness can help him avoid trouble, and partly because it can help him to make great progress without being paralyzed by fear of possible legal consequences. There are four pieces in the sequel which I hope you'll find interesting and useful. They are as follows: 2) A paper by David Kay entitled "A Course in Computer Law". Dr Kay is both a CS professor and a lawyer, and thus he speaks with authority in both domains. 3) A memo by Anonymous entitled "The IPL Top 5" (IPL = Intellectual Property Law). Anonymous is a patent attorney at large corporation. 4) A paper by Jeff McAllister entitled "The Legal Standard of Professionalism". Jeff is a graduate student in the MS CS/ SE Track at UAF who has recently completed a required semester course on legal principles. This paper was part of that course. The course was intended to be one on software-related law specifically, but it is actually a mixture of intellectual property law and contract law taught with a software spin by a local Fairbanks attorney. 5) A listing by me entitled "Some Recommended Sources". It is included because all of them are inexpensive or free, easy for a non-lawyer to understand, and proven helpful to me to some extent. Books, technical journals, and some web items are included. ###################################################################### 2) A COURSE IN COMPUTER LAW David G. Kay Department of Information and Computer Science University of California Irvine, California 92697-3425 kay@uci.edu Abstract We describe a course for computer science students that covers the legal issues that apply to computing, from intellectual property protection to liability for system failures to computer crime. Beyond their intellectual interest, these issues have practical impact on the work of nearly every computer scientist. This course gives students a framework for recognizing these issues, to avoid them or to seek professional advice as appropriate. Your web-indexing program has worked for weeks compiling a catalog of cinema-related information on the net. One day you get a letter from Disney Pictures demanding that you remove from your index everything gathered from their web sites, all of which bear a copyright notice. Do you have to do it? The next day, you hear from the lawyers at Netscape, who claim your indexer infringes a patent they hold. They demand that you pay them a licensing fee for each search a user performs with your software. How do you avoid this? You were the lead programmer for a pattern recognition package that was used in an air traffic control system. Two planes have a near miss over O'hare, seriously injuring two dozen passengers, and the FAA investigation determines that an off-by-one error in your code caused the accident. The injured passengers file a $100-million lawsuit, naming you among others. How do you protect yourself? Since 1984, the author has offered a course for computer science students that addresses these and other issues that arise when the legal system deals with computing technology. Course structure This computer law course is offered as a seminar for university graduate students in computer science. As such, it involves a good deal of independent reading, classroom discussion, student research projects, and a take-home final exam. The same material could easily be offered to advanced undergraduates (indeed, such students have successfully completed the author's graduate course), perhaps with more structured assignments and exams. Unfortunately, there is no current text that covers this field at a level and price appropriate to non-lawyers. Bigelow and Nycum[1] and Mandell[2] are long out of date; Gemignani[3], Nimmer[4], and Shue and Vergari[5] are quite expensive and oriented primarily to the practitioner. Tunick[6] and Maggs, Soma, and Sprowl[7] are aimed at an introductory audience, but they follow the traditional law textbook approach of providing many short excerpts from source materials with essentially no expository guidance to the reader. Perritt[16] and Cavazos and Morin [17] cover internet (or cyberspace) law, which omits issues that arise outside of the internet context. In our course we use selected readings from periodicals such as those listed in the references, some of which are available on line. One notable resource is the on-line course, Cyberspace Law for Non-Lawyers by Lessig, Post, and Volokh[18]. Broad coverage The course focuses on substantive legal issues, as described in more detail in the following sections. We do not cover computer applications to law practice (although occasionally a student research project examines Lexis or Westlaw, the computerized legal research systems), nor do we cover the use of expert systems or other artificial intelligence techniques to model legal knowledge or reasoning. Overview of the legal system The course begins with a brief overview of the American legal system, from the case-based common law to Federalism and the parallel State and Federal courts, legislatures, and bodies of law. Even American-born students may not appreciate the system fully (indeed, one might analogize the Founding Fathers' distrust of a centralized government to a rationale for distributed computing systems), and of course many students learned their civics overseas. We note that as computer science can be divided "horizontally" into sub-disciplines (such as architecture, databases, theory, and software engineering), so can the law (into contract law, criminal law, intellectual property, torts, and so on). At the same time, we can categorize computing "vertically" by application area (aerospace, film-making, scientific visualization) just as we can with the law (banking law, health care law, gambling law). Computer law is one of these vertical categories which itself is sometimes subdivided, for example into internet law, information law, or electronic commerce law. We point out in particular the conflict between fast-moving technology (which is good) and the slow-moving legal system (which is also good, since we don't want the rules that govern our whole society to change too quickly out from under us). The law does have difficulty keeping up; legislation written ten years ago protecting privacy of data might apply to "magnetic storage media," and thus inadvertently exclude optical storage. Moreover, most of the law in this area evolves case by case, with each case taking years to come to trial and still longer to produce an appellate court's opinion usable as a precedent for future action. In the author's opinion, the very few legal issues that have been finally settled have come out technically "right" from the perspective of computer scientists, but the process is a long and tortuous one, incomplete in most areas. The time scale for legal change, on the order of decades, contrasts sharply with the time scale for change in computing (either nanoseconds in the processor or the doubling of capacity every year or so). Many computer scientists find this disparity frustrating. The imprecise nature of evolutionary change in the legal system also frustrates computer scientists. Not only do some individual decisions come out incorrectly during the long journey to settling an issue, but also legal change, dependent as it is on achieving human agreement, is much less under the control of the individual computer scientist than his or her own software development would be. There, after all, one can fire up the editor, tweak the code, recompile, and have one's universe changed within a minute. The law, with its evolutionary nature and reliance on precedent, carries the concept of code reuse to heights undreamed of by software engineers. In computing we undertake total rewrites of our code from time to time, but starting over from scratch is exceptionally rare in the legal system. This is not altogether bad, since it supports stability in society, but it does lead to complex layering of legal rules and internal inconsistencies that we would not accept in computer software. Intellectual property rights in software The Constitution gives authors and inventors an incentive to create by providing them with the exclusive rights to their creations for a limited time. Society benefits when these creations come into the public eye. The legal protection for these creations makes up intellectual property law, but the traditional categories of intellectual property protection (patent and copyright at the Federal level, trade secret in the States) don't cleanly apply to software. Software is utilitarian (and thus perhaps patentable), a creative writing (perhaps copyrightable), and often jealously guarded (thus protectable by trade secret law). Each of these categories has been applied to protecting software, with mixed results. Moreover, there are those such as Richard Stallman's Free Software Foundation who question the very premise that software should be protected and restricted in its dissemination, in marked contrast to the Software Publishers' Association, which stages raids on corporations suspected of using software in violation of copyright or other restrictions. This topic is the single largest of the course, because the most has already been decided in this area. We discuss the legal issues, their practical application, and their social and economic effects. Contracting for computer systems Most frequently, computing-related disputes involve contracts--legally enforceable promises that should state as unambiguously as possible who promises to do what and what the criteria are for satisfactory performance. Contracts for custom software should specify the required functionality, response time, reliability, installation, and support, among other issues, yet determining these unambiguously may require much of the work to be completed in advance. As with other large, technologically complex systems, development (and payment) usually proceed incrementally from milestone to milestone, since the scope of the outcome is unclear at the outset. One common provision unique to computing contracts is source code escrow: The seller of custom software may not want to divulge the source code, but the buyer may want to know that the code will remain accessible if the seller goes out of business, so the parties deposit a copy of the source code with an independent third-party escrow holder, giving specific instructions about the circumstances under which the code may be released to the buyer. With mass-market software, the issues center more around the formation and enforceability of contracts in such forms as shrink-wrap licenses and disclaimers of warranties. The emergence of electronic commerce on the internet constitutes yet another area of contract law, in which the allocation of responsibility among the parties may be different than for physically-based transactions. Computer crime and abuse We can divide computer crime into four categories: Crimes motivated by financial gain, unauthorized access to computer systems ("cracking" or "hacking") without financial motivation, physical vandalism, and espionage (either industrial or international). We examine cases, some celebrated and some not, using source materials rather than popular press accounts; we cover the differences between computer crimes and more time-honored misdeeds; and we discuss policies that might curtail such abuse. Privacy The potential for improper use of private information maintained about individuals by government and private industry existed before computers, but computers allow recordkeepers to gather more information, save it longer, search it at computer speeds, and combine and analyze data collections to produce qualitatively different information about the individual data subjects than they could with paper-based record systems. Some legislation at both the Federal and State level exists, and more has been proposed, to protect the privacy of information, but such legislation has a commercial cost which recordkeepers are quick to point out. Other privacy-related issues include automatic identification of telephone callers (Caller ID), monitoring of employees' performance and communications in the workplace, the data stored as "cookies" in internet transactions, and databases maintained by associations of landlords or physicians to screen out potential tenants who have previously been evicted or patients who have filed malpractice suits. Liability for malfunction Computer professionals know that complex computing systems always contain flaws. These flaws occasionally have effects that cause personal injury or property damage. Those injured can seek redress under various legal doctrines. The doctrine of negligence requires that whoever caused the injury have acted contrary to some reasonable standard of care--but what is the standard, careful method for developing software? There is no generally accepted and applied standard; no matter what we as college software educators might try to instill in our students, there are still plenty of hackers out there writing commercially successful software. The doctrine of strict liability states that producers of defective or inherently dangerous products are responsible for injuries their products cause, no matter how careful they are. Strict liability has not yet been applied to computer systems, but the prudent software producer could arrange insurance or contractual protection against such liability. The use of expert systems technology gives rise to other questions of liability. Should a doctor be liable for relying on an expert diagnosis system and giving incorrect treatment based on its diagnosis? Should the doctor who makes an incorrect diagnosis unassisted be liable for failing to consult such a system? If the system gives incorrect advice, should its programmer, the "knowledge engineer," or the expert whose knowledge was encapsulated bear any responsibility? These questions are unresolved at present, but cases that involve them are likely to arise before long. The Year 2000 problem will also raise liability issues: Should a programmer in the 1960s have contemplated the effects of the millennium change? What about in the mid-1990s? How should responsibility be allocated for the failures of globally interdependent systems? Other topics As time permits, we cover other topics such as professional ethics in computing (using Donn Parker's scenarios[8], we explore the lack of agreement on ethical norms in computing), computer-related litigation and evidence (particularly how current technology can produce impeccable forgeries of previously credible evidence such as photographs), antitrust issues (where Microsoft's current problems recall those of IBM in the 1970s), transborder data flow and international information transfer, taxation of computer systems, and electronic funds transfer systems. Conclusion Students, many of whom hope to succeed commercially, appreciate the real-world applicability of this course. They also benefit from studying a subject area whose underlying rules and modes of analysis are more fluid and less susceptible to mathematically formal resolution than conventional computer science topics. The student evaluations are consistently quite high. The author, too, finds it a pleasure to discuss these issues with an audience already familiar with spreadsheets and graphical user interfaces, one that knows such distinctions as object code and source code or linear vs. logarithmic search algorithms. While nobody should attempt on the strength of one course to handle his or her own legal affairs unaided, this course does provide enough awareness of the issues to prompt consultation with a professional when appropriate and to prompt caution when contemplating risky behavior (such as taking code from one job to another, capturing extensive personal information from on-line transactions, or posting egregious flames to the net). In addition to his education in computer science, the author does have a legal education and is licensed to practice law. However, this course could be taught by a non-lawyer computer scientist well versed in legal reasoning and the operation of the legal system; of course the instructor would have to keep up with the rapid changes in this field through such publications as [9-15]. It would be ideal to team up with a lawyer practicing in the high-technology area, or with a law professor familiar with the area; in fact, a course open both to law students and to computer science students would provide fruitful opportunities for cross-cultural learning and synergistic research projects. This course has been offered annually since 1984, first at UCLA and later at UC Irvine. One recurring theme is the need for better education about computing on the part of lawyers, judges, and policymakers. One cannot appreciate the implications of technology policies simply by reading a book or a few articles. All of us as computing educators must remember that our non-majors may come to make policy that affects us, and redouble our efforts to provide them the tools to do it wisely. From the opposite perspective, courses such as this one may encourage students with significant computing expertise to become policymakers themselves. [An earlier version of this paper appeared in the Proceedings of Twenty-Third SIGCSE Technical Symposium on Computer Science Education, March 1992.] References: [1] Bigelow, Robert P., and Susan H. Nycum, Your Computer and the Law (Prentice-Hall 1975). [2] Mandell, Steven L., Computers, Data Processing, and the Law (West 1984). [3] Gemignani, Michael C., Computer Law (Lawyers Co-operative 1991). [4] Nimmer, Raymond T., The Law of Computer Technology (Warren, Gorham & Lamont 1985, updated twice annually). [5] Shue, Virginia V., and Jeams V. Vergari, Fundamentals of Computer--High Technology Law (American Law Institute--American Bar Association 1991). [6] Tunick, David C., Computers and the Law: Cases and Materials (John Marshall, 1991). [7] Maggs, Peter B., John T. Soma, and James A. Sprowl, Computer Law: Cases - Comments - Questions (West 1992). [8] Parker, Donn B. Ethical Conflicts in Computer Science and Technology, AFIPS Press, 1977. [9] The Computer Lawyer, published monthly by Aspen Law & Business. [10] Privacy Journal, published monthly by Robert Ellis Smith. [11] Rutgers Computer and Technology Law Journal, published by the Rutgers University School of Law. [12] The Computer/Law Journal, published quarterly by the Center for Computer/Law. [13] The Software Law Journal, published by the Center for Computer/Law. [14] Harvard Journal of Law and Technology, published by the Harvard Law School, http://www.law.harvard.edu/home/jolt/ . [15] High Technology Law Journal, published by Boalt Hall School of Law, University of California, Berkeley, http://www.law.berkeley.edu/btlj/ . [16] Perritt, Jr., Henry H., Law and the Information Superhighway, J. Wiley, 1996 (with periodic updates). [17] Cavazos, Edward A., and Gavino Morin, Cyberspace and the Law, MIT Press, 1994. [18] Lessig, Lawrence, David Post, and Eugene Volokh, Cyberspace Law for Non-Lawyers, http://www.ssrn.com/update/lsn/cyberspace/csl_lessons.html . ###################################################################### 3) IPL Top 5 Anonymous Patent Attorney, Large Corporation The following five maxims are big company thoughts. A large corporation may have a large legal staff, while smaller companies might not even have an attorney or have money to spend on patent protection. However, the general principles are universal. 1) Look before you leap - code or information that appears to be FREE may not be. Make sure that the cost of using code or information from another entity (i.e., company or individual) is well understood up front. If you intend to use the code, ideas, concepts, or techniques in a product, make sure that: 1) you know the terms and conditions under which the code or information is being received (money, permissible uses, etc.) and 2) the rights under which the entity grants you permission to use the code or information (i.e., is the code or information really theirs?) are documented and saved (see maxim 3 below). 2) If you think something is a good idea, it probably is. Computer system hardware is becoming more and more of a commodity every day, which causes customers to make purchase decisions based solely on software value. This industry trend has resulted in a focus on software related patents and other intellectual property protections. 3) Always listen to your mom, except when she tells you to clean out those old legal files. Keep those old legal files (i.e., letters, contracts, licenses, etc.). Someday, a 3 or 4 year old document may save you and your company a lot of money. I should also say that sometimes information in an old file proves embarrassing, but overall it's better to retain the information than not. 4) E-Mail lasts forever. When you send a note or a letter, don't say anything that you might be embarrassed about later. This is particularly a problem with e-mail. People tend to think that an e-mail note is gone when deleted by the recipient. This intuitive conclusion is typically incorrect. E-mail is often times preserved in network logs that are kept for very long periods of time. When one company sues another, one of the first things they ask for is the other company's e-mail logs. 5) If you don't know what to do, ask someone who does. If you have a legal question, ask a lawyer. You don't want to be making legal decisions for your company. If you don't have access to a lawyer, ask someone else who has the authority to make such decision. It 's also in your personal interest to document the decision and who made it (e.g., through e-mail). ###################################################################### 4) The Legal Standard of Professionalism Jeff McAllister Graduate Student, University of Alaska Fairbanks MS CS/Software Engineering Track ftjsm@aurora.alaska.edu >From a non-software-engineering perspective, software engineering needs inputs from other disciplines. This is because in SE as in other fields the results of inbreeding tend to get ugly. One curious fact from the legal perspective decries a serious lack: there is no such thing as software malpractice. Why? A peek into the legal mind provides a disturbing explanation. There is insufficient evidence to show that programmers know how to learn from each other, much less from the rest of the world. Paying attention to the law's definitions of professionalism makes sense, both in staying out of court and figuring out how to make software engineering a fully developed profession. Here's an overview of the malpractice situation. There is no software malpractice because there is no professional standard, and there is no professional standard because there is no core body of knowledge that expert witnesses would need to be consulted about. And this lack of a core should be a matter of concern. This means that there is little reason not to believe that CS grads and CS professionals are merely getting paid to do what teenage hackers do for free at home. In this light, auto mechanics and beauticians are more professional -- and this reflects how they have been treated in court. The courts have kept to this evaluation nearly 20 years. Lawyers must still be careful to set up their cases so there is no chance they could be accused of proposing professional negligence. This has occurred since the oft-quoted Chatlos case, where the presiding judge stated: "The novel concept of a new tort called 'computer malpractice' is premised upon a theory of elevated responsibility on the part of those who render computer sales and service. Plaintiff equates the sale and servicing of computer systems with established theories of professional malpractice. Simply because an activity is technically complex and important to the business community does not mean that greater potential liability must attach. In the absence of sound precedential authority, the Court declines the invitation to create a new tort." (Chatlos Systems vs National Cash Register Corp. 479 F. Supp 738 (1979)) This isn't just stating that software malpractice has tended to involve mostly monetary amounts, and not risk to life or limb. This "theory of elevated responsibility" goes far deeper. A professional standard implies a lot of things. Professionals are evaluated at a different level than other workers. The general standard of reasonableness as a yardstick against which to measure negligence is replaced with the testimony of peers. In a truly professional field, the court realizes that practitioners will work from a core body of knowledge which allows them to focus on those details (some of which would seem irrelevant to an outsider's mind) necessary to get the job done. Doctors are expected to instinctually understand the nuances and harmonies of human bodies which remain mysterious to the rest of us. So, since a judge and jury cannot be expected to learn what would be necessary to decide whether someone has truly done as much as should be expected, "experts" are called. These experts are treated not as individuals but as mouthpieces for the core body of knowledge. Professionals are expected to think enough alike to be considered a coherent group. In effect, a recognized professional field is given a great amount of autonomy in deciding what is negligent and what is not. There are greater penalties, true, but this is due to the perception that negligence is a lack of care while malpractice is a breach of personal integrity. The public must be able to trust that a good definition of how that profession should serve the public good exists in the profession's ideals, and that practitioners know how to distinguish between those who keep to those ideals and those who merely wish to serve themselves. Professionals may be sued for malpractice because the perception of "higher standards of care" imposed on them is inseparable from a higher level of trust. When there are no ethics, this trust cannot be given. By this definition, professionalism is more related to shared knowledge, cooperation, and public trust than it is to a collection (however vast) of purely technical knowledge. >From this perspective, it seems that worrying about techniques alone misses the point. If software engineering degenerates to a "bag of tricks" or continues to seem like the "addition" of documentation to status quo programming, then it can't help but make software engineering seem "gimmicky", and more for managers than for the people actually writing the code. I propose a definition of software engineering here to help bridge the gap between where the field is now and where it should be -- and to fit it into the legal background like other professional fields. "Software engineering is an attempt to create a framework through which programmers can become more aware of what they do and what the completion of large projects really involves, using quantitative means to increase their ability to 'see' what they are doing and communicate how to do it better." Software engineering, at this stage in its development, seems to be about creating a core body of knowledge. Requirements, planning, design, testing, etc. can be seen as attempts to figure out a basic vocabulary upon which the future foundations of professional programming can be laid. It is about communicating the results of experience so that: (1) practitioners can start their careers using the lessons that others have spent theirs learning and (2) so that this similarity makes efforts on current projects more communicable so that large numbers of programmers can participate in realizing projects which would be impossible using methods they could figure out on their own. Awareness of other professions can contribute much to a developing field like software engineering. As the year 2000 approaches, a professional standard might come in handy when evaluating the intricacies of working with legacy code. But beyond this is the knowledge of the basic definitions of professionalism that established engineering fields have to meet. If software engineering were to more seriously pursue these, it seems that it might get be much closer to realizing its goals of 30 years ago. There's so much frustration in keeping up with the hardware. But the answers to the fundamental questions may just lie in more human directions -- communication, ethics, etc. The threat of legal consequences could be considered a helpful goad: away from relying entirely on the keyboard and calculator, and toward the real world. ###################################################################### 5) Some Recommended Sources Pete Knoke CS Prof, UAF ffpjk@aurora.alaska.edu Here are some software-related law sources that are easily accessible to persons like me. "Accessible" means affordable, easy to obtain, easy for a non-lawyer to understand, and usually reasonably brief. I list some books, some technical journals, and some Web sites below, together with a few comments. BOOKS ----- 1) "Future Codes: Essays in Advanced Computer Technology and the Law", Curtis E. A. Karnow, Artech House, 1997. I've read quite a bit of this book, and I find it delightful. The author is a practicing California attorney and judge with a very strong interest in technology. He impresses me with his considerable knowledge of computers. His essays often deal with legal first principles (e.g. the "reasonable man" concept) 2) "CyberLaw: The Law of the Internet", Jonathan Rosenoer, IEEE Computer Society Press, 1997 Mr. Rosenoer is a California lawyer. As the title implies, the book's focus is on Internet law. I've not yet read the whole book carefully. Some parts have been helpful already, e.g. Chap 14, A Context: Legal Developments, Late 1990 to Early 1996. 3) "Patents, Copyrights and Trademarks", 2nd ed., Frank H. Foster and Robert L. Shook, Wiley, 1993 Intellectual property law for the layman. No particular focus on computers and technology. 4) "Software Development: A Legal Guide", 2nd ed., Stephen Fishman, Nolo Press, 1998. Dvorak of PC Magazine calls it "An amazing book! A must for Anyone in the software business ...". Includes intellectual property law, software development and license agreements, and more. Also includes a CD-ROM with forms, etc. I have the book, but haven't yet looked at it very closely. 5) "Testing Computer Software", 2nd ed., Cem Kaner, Jack Falk, and Hung Quoc Nguyen, Thomson Computer Press, 1993 Looks good to me so far as the book's subject is concerned. Regarding legal matters, Chapter 14 is entitled "Legal Consequences of Defective Software". This book was recommended to me by a FASE reader. TECHNICAL JOURNALS ------------------ 1) Communications of the ACM ------------------------- Often has a column called Legally Speaking, written by Pamela Samuelson Usually has a column called Inside Risks, usually written by Peter G. Neumann Occasionally has a major article on legal issues. For example, the Feb 1998 issue (Vol 41, No 2) has the following article: "Practical Legal Aspects of Reverse Engineering", by Brian B. Behrens and Reuven R. Levary. 2) ACM Software Engineering Notes (SIGSE Publication) ----------------------------------------------------- Always has a column entitled "Risks to the Public", by Peter G. Neumann and contributors. Full of potential legal implications 3) IEEE Micro ------------- Almost always has a column by Richard Stern, called Micro Law. Usually excellent. 4) IEEE Computer ---------------- Occasional law-related articles 5) IEEE Software ---------------- Occasional law-related articles WEB --- 1) Search on "computer law" and you'll get lots of hits (13675 with HotBot on 13 Apr 98). 2) "Computer Law Observer" by William Galkin Esq. is usually interesting, and it's free. There's also an "International Computer Law Observer". (http://www.lawcircle.com/observer) 3) Numerous other sources, far too many to mention. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Next Month's Topic: 100th Issue - FASE: Past and Future The May 1998 issue of FASE will be its 100th. The topic for that issue is titled "FASE: Past and Future". Besides looking at some of the highlights of the first 100 issues of FASE, this article will look at the possibilities and predictions for the future. Also, the past and potential futures of publication in the software engineering education and training field will also be examined. I want to hear from you on these subjects. In particular, I'd like for you to address any or all of the following questions? 1. What are your thoughts and memories (good and bad) about FASE as it reaches issue 100? 2. What's your opinion about the past and current state of software engineering education and training publication? (e.g. journals, proceedings, newsletters, special issues, books, technical reports) 3. What do you see FASE evolving into over the next several years? 4. What's your opinion on the future of software engineering education and training publication? Please send your reminisces, historical facts, predictions, and opinions to me at bagert@ttu.edu by May 8. Thanks! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming topics June 1998: Software Metrics Education and Training Guest Editor: Susan Mengel, Texas Tech University mengel@ttu.edu July 1998: Licensing of Professional Engineers in SE Editor: Don Bagert, Texas Tech University bagert@ttu.edu Aug 1998: To be scheduled Sept 1998: Graduate SE Program Survey Results and Evaluation Guest Editor: Pete Knoke, University of Alaska Fairbanks ffpjk@aurora.alaska.edu Oct 1998: SEE&T Outside of the U.S. Guest Editor: Michael Ryan, Dublin City University mryan@compapp.dcu.ie TBD: Software Engineering Ethics Education and Training Guest Editor: Don Gotterbarn, East Tennesse State gotterba@etsu.edu All dates are subject to change. For more information about a particular issue's topic, please contact the corresponding guest editor. Here are some of the other topics planned for future issues: * Accreditation * Curriculum Models * Distance Learning * Object Technology Education and Training * Software Survivability Education * Student Team Projects Please send any suggestions for future topics to bagert@ttu.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Departments ###################################################################### By: Don Bagert (Academic/Misc Editor) FASE Archive: Back Issues Located; Complete Set Now Available I asked for back issues last month, and I got them! Thanks to David Budgen, Jenny Harvey, Timothy Shimeall, Richard Upchurch, and Rick Zaccone for their help in providing the missing issues. Last issue, I mentioned that I thought that Volume 3, Number 4 was actually mistitled Volume 3, Number 5. However, David Budgen pointed out it is actually mistitled Volume 3, Number 6. As previously stated, the real Volume 3, Number 5 issued an apology for the mistake at the beginning of the issue. (I have put a note of explanation on top of the copy of Volume 3, Number 4 in the FASE archive.) I mentioned that Volume 3, Number 9 was a "lost" issue of FASE...I now believe that I know why. Both Volume 3, Number 9 and Volume 4, Number 1 were sublabeled "FASE #19" when the latter issue was actually #20. There is now an ftp archive of all previous issues of FASE available via anonymous ftp at . A web page with a table of contents for each issue will be available through the FASE home page sometime during the next month, and will be announced in the next issue. ###################################################################### By: Don Bagert (Academic/Misc Editor) FASE Formatting: Feedback More Positive Apparently, the software that I engineered to check last issue's format worked, and there were no problems with line length or unreadable characters. Hopefully, this will continue to be the case. I only had one person that sent me an email requesting that their issue split into parts, so we won't be doing a separate "two-part" mailing at this time. However, we will of course reconsider providing this service if more people request it. I now feel that I can start investigating using a "digest format" for FASE, so may we try an issue that way before the end of the year. Finding the time or resources to do both HMTL and ASCII versions of FASE is probably a little farther in the future. As always, we welcome any comments about the format of FASE. ###################################################################### By: Don Bagert (Academic/Misc Editor) Curriculum Model Resources Shortly after last month's issue, a reader asked for some pointers to software engineering undergraduate curriculum model resources. Of course, the IEEE-CS/ACM Steering Committee for the Establishment of Software Engineering as a Profession has an education task force working on a curriculum model, and the Working Group on Software Engineering Education and Training has a team that is also looking into that issue [See separate article with minutes of the last Working Group meeting.] However, what resources (both undergraduate and graduate) are there right now? Probably the most important SE curriculum documents in the United States have been published by the Software Engineering Institute: 1990 SEI Report on Undergraduate Software Engineering Education by Gary Ford, CMU/SEI-90-TR-3. 1991 SEI Report on Graduate Software Engineering Education by Gary Ford, CMU/SEI-91-TR-2. 1994 A Progress Report on Undergraduate Software Engineering Education, Ford, CMU/SEI-94-TR-11. All of these documents (plus others involving individual subjects) are available via . The graduate report is an especially detailed curriculum model. The 1990 undergraduate report provides a framework for a undergraduate SE curriculum, while the 1994 report mainly discusses undergraduate software engineering education efforts at various universities. There is "A Report on Undergraduate Curricula for Software-Engineering", which was a joint effort between the British Computer Society and the Institution of Electrical Engineers, and was published by the latter organization in 1989. I have not seen this report yet; can anyone supply me with more information? If you have any other suggestions of sources for undergraduate and graduate software engineering curriculum models, please send them to me at bagert@ttu.edu. I will publish the results in a future issue. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### By: Don Bagert (Academic/Misc Editor) Texas Board of Professional Engineers - Update [Editor's Note: This article is the latest of a continuing series on the efforts of the Texas Board of Professional Engineers in the area of software engineering. Please refer to the December 1997, January 1998, and March 1998 issues of FASE for a summary of previous events.] Several members of the Software Engineering Advisory Committee of the Texas Board of Professional Engineers had an informal meeting in Austin on 14 April. The committee discussed recommendations for the implementation of software engineering as a professional engineering branch licensed by the Board, if the discipline is given final approval by the Texas Board at its next scheduled meeting on 17 June. Articles concerning the Texas Board's recent work related to software engineering can be found in the next issues of ACM Software Engineering Notes and the Engineering Times of NSPE (the National Society of Professional Engineers). ###################################################################### By: Don Bagert (Academic/Misc Editor) A Further Summary of Events in Atlanta 21 Feb - 1 Mar 1998 In the last issue of FASE, a summary of the workshop "Software Education 2000: Computing at the Crossroads" was presented, with a promise to summarize events from the remainder of that week in Atlanta in this issue. On February 21-22, the Working Group on Software Engineering Education and Training met at Georgia Tech. The minutes of that meeting are in the article immediately below. The Conference of Software Engineering Education and Training was on February 23-25 at the Georgia Center for Advanced Telecommunications Technology, with a day of workshops (including "Software Education 2000") on the final day. On Tuesday evening, there was a meeting of the IEEE-CS Technical Committee on Software Engineering Education, led by Laurie Werth. The ACM SIGCSE Symposium on Computer Science Education was held at the Marriott Marquis on February 25-March 1. There were several sessions related to software engineering, including a birds-of-a-feather session where SE accreditation, curriculum, and licensing issues were discussed. The future of software engineering education, and its possible effects on current computer science programs, was one of the major topics of Symposium's first-ever "Town Meeting". The ACM International Collegiate Programming Contest (ICPC) Finals was held on February 28. Charles University of Prague won this year's competition; details are at . ###################################################################### From: Nancy Mead Working Group on Software Engineering Education and Training Georgia Tech February 21-22, 1998 MEETING MINUTES =============== Attendees: Don Bagert, Texas Tech University; Neal Coulter, FAU; Jack Crowe*, Auburn University; Jorge Diaz-Herrera*, Monmouth University; Morven Gentleman*, National Research Council of Canada; Tom Hilburn, Embry-Riddle Aeronautical University; Greg Hislop, Drexel University; Pete Knoke, University of Alaska Fairbanks; Jimmy Lawrence*, Auburn University; Mike Lutz*, RIT; Nancy Mead, SEI; Susan Mengel, Texas Tech University; Melody Moore, Georgia Tech; Fernando Naveda*, RIT; Dale Oexmann Rose-Hulman Institute of Technology; Erna Olislaegers*, Philips Research; George O'Mary, Boeing; Michael Ryan, Dublin City University; Hossein Saiedian*, University of Nebraska at Omaha; Sheneui Sloan, CSULB; Perla Unpingco, Lockheed Martin; Laurie Werth*, University of Texas at Austin * partial attendance FUTURE MEETING SCHEDULE ======================= The next meeting will be held in conjunction with the Frontiers in Education conference in Tempe. Tentative meeting dates are November 3-4, assuming the FIE starts the afternoon of November 4. Possible meeting locations were suggested by Neal Coulter and George O'Mary. We will also meet next year in conjunction with CSEE&T in New Orleans. The meeting will be held on March 20-21. KEYNOTE SPEAKER =============== Melody Moore, a professor at Georgia Tech and Georgia State universities gave the keynote talk and demo of the Classroom 2000 and its use in the Real World Lab. It generated a lot of interest and discussion. Some of us attempted use of the 'live board' with varying levels of success (it's a lot harder than it looks). Melody also was our host for the meeting, and we greatly appreciated her help and participation. ACTION ITEMS FROM NOVEMBER ========================== Team 1 - Solutions/Actions Kathy Beckman, Jack Crowe, Nancy Mead, George O'Mary, Sheneui Sloan, and Frances Van Scoy 1.Survey - Survey out 11/17 - Done by Sheneui - Survey returned 12/15 - Email reminder 12/1 - Done by Sheneui - Phone call 12/8 - Done by George - unlimited public distribution 2.White paper (SEI report) - later post conference - background - the problem, the urgency - benefits and constraints - case studies - Industry-CFO's/CIO's (CIO Magazine Inc., small business) 3.Audience - good will messages - University office of sponsored programs - Continuing Education/off-campus instruction - Research and Economic Development - Business School 4.Build partnerships with staffing firms, watch Jack Crowe - be selective - transition strategy (+loyalty) vs. "bought talent" (-loyalty) 5.Publish in magazines - Fortune - 1 paragraph - CIO - Training - Inc - Chronicle of Higher Education 6.Invite current collaborators to CSEE&T (2/98) - Done by Sheneui - industry and university best practice exchange - reception/food - Jack Crowe working on sponsor - check with conference chairs for program options (11/4) - done - categorize information; similar types and share best practices - survey results - present - Nancy has these in draft form (2/98) - publish results CANCELLED DUE TO LACK OF RESPONSE - RESPONDENTS INVITED TO WG MEETING 7.Panel (1999 SIGSCE) - (If 6 is good, then 7) Action Items 1 - Sheneui Sloan and George O'Mary - February, 1998 2 and 3 - Working Group Team - Summer, 1998 4 - On watch, Jack Crowe - February, 1998 5 - Working Group Team - Summer, 1998 6 - Kathy Beckman - February, 1998 7 - Future, Frances Van Scoy - Summer, 1998 ======================= Team 2 - SE Curriculum Don Bagert, Tom Hilburn, Susan Mengel, and Dale Oexmann Action Item: Guidelines for Software Education ("Straw Horse" for software engineering curriculum model) Milestones 11/14 2-page description 1. Preamble (objective, rationale, philosophy) 2. Description of knowledge units (like curriculum 91) - short narrative - list of topics - time devoted 3. Describe various ways a curriculum could be implemented. - IS program - SE/CE/EE program - CS program 1/16 Partial "rough" draft and review by Team 2 2/22 Complete "smooth" draft and review by working group, CSEE BOF, and SIGCSE BOF. 3/15 Revise and Disseminate 8/98 Ireland Conference - workshop proposal and paper proposal submitted. ====================================================================== CURRENT WORK - FEBRUARY 1998 MEETING ==================================== TEAM 1 - Industry-University Collaboration Participants: Neal Coulter, Jack Crowe, Jimmy Lawrence, Mike Lutz, Nancy Mead, George O'Mary, Sheneui Sloan, Perla Unpingco Summary SEI Software Engineering Education Working Group Team 2 conducted a survey of 48 industry and university participants involved in software engineering education and training. Of the 48 surveyed, 27% or 13 responses were received. The working group reviewed the survey responses to determine any trends, improve questions for conducting follow-up interviews, and validate the goal of defining the "best practices" for industry/university collaboration in a final report to be published by the SEI. Discussion Initial survey goals and objectives. The team revisited the goals and need for the survey and concluded that survey was necessary to identify and define the process for collaboration between industry and university --there was no need to "reinvent the wheel". Further, that successful models for the collaboration would be identified and serve to assist others in achieving the expected benefits from a mutual relationship. The team agreed to use the definition of collaboration as written in the Attachment 2. Key trends identified by the working group. The team reviewed each question and corresponding response to produce the preliminary profile of the industry/university collaboration. - Active for a period 3-5 years (length may result from the need to refresh the curriculum) - Funded by charging fees, some cost sharing, other fee-based approach or in-kind support - Typical activity sponsored is the classroom - Annual attendance or participants range from 1 - 100 persons - Goals and measures of the collaboration are ranked from (1 - high, 10 - low) include: 1. Fulfill organizations educational mission 2. Access to education and training resources 3. Competitive advantage 4. Business growth 5. Cost savings 6. Enhanced organizational reputation 7. Revenue 8. Access to research and tools resources 9. Staffing source (interns new hires) 10. Supplement software engineering training, offered in-house (write-in) - Collaboration goals, processes, and procedures are documented - Most respondents stated that their goals were achieved and measured using customer satisfaction, financial, and attendance metrics. - Memorandum of agreement, charter, or contract formalized the collaboration between industry and the university - A steering committee comprised of either a technical and administrative group typically guided the collaboration - Requirements for collaboration activities are determined using differing approaches to include membership survey, active marketing, industry need assessments - An average of 3 or more persons (full-time?) was needed to support the collaboration activities. Note: no differentiation as to the ratio of support required (industry: university) - Improvements to the collaboration activity are determined by capturing lessons learned and holding evaluation meetings. Lessons learned include: - Good and continued communication is vital, meet regularly - Document everything - define expectations, incorporate evaluation measures, memorandum of understanding - Focus on common goals between university professor's interest and industry needs - Define roles and responsibilities - universities need to coordinate and administer program activities - Understand the "culture" of the industry participants - Don't expect instant success, takes time to grow, initial activities may not succeed - Expect significant staff time on both sides when establishing the collaboration - You have to work at it and hold it together Benefits realized from the collaboration include: - Outreach such as extends reach of the university - Revenue, cost savings or other financial benefits - Communications or public relations to include name recognition, good public relationship, better recognition between university and industry - Partnership and relationship building such as shared reward and risk, shared resources, visibility of university perception of serving industry's needs, an appreciation of the role of software in industry - Employment sources of interns and potential hires - Products and Services fulfills company training requirements for specific courses, academic courses supplement industry training; provides a procedure for taking research through to production Action Items: Conduct follow-up interviews and questionnaire construction. - Target: 5 collaborations - pilot interview questionnaire (optional) - interview candidates chosen based on selection criteria - send notification letter to interview candidates - minimum of two person per interview team representing academia and industry - interview to last no longer than one hour - request collateral material from interview candidates before interview - summarize response for review Selection criteria for interview candidates: - Collaboration has existed one or more years (Q IA) - mutual planning process used to determine collaboration, goals, and mission (Q IID) - formal collaboration and processes documented (Q IIIB & IIIG) - operational decisions between industry/government organization and university by consensus (Q IIIC) Final report to define the "best practices" for industry/university collaboration. Report to answer the following questions: - How to start a collaboration? - How do you know if a collaboration is successful? - What are some spin-off activities from a successful collaboration? - What is documented in the collaboration process? Tasks/Timeline Part 1 of survey - 48 surveys mailed (11/97) - 13 completed surveys returned (12/97) Part 2 of survey - Follow-up interviews of selected collaborations that responded __________________________________ - Reviewed and reported on preliminary data patterns (2/21/98) - some responses to survey questions were unclear - additional info/data needed - Conduct part 2 of survey (see below) Part 2 - Interviews Select Interview Candidates Get additional surveys send letter - Sheneui (4/1/98) Kathy/Nancy (4/15/98) Nancy to provide sample ltr (3/15/98) Questions (10) - Draft for review Summarize ALL survey Sheneui/George (4/1/98) results - Nancy Finalize questions (4/15/98) pilot one - optional (5/1/98) Interviews - All (6/1/98) Select additional Feedback interview candidates All data to Nancy (8/1/98) Kathy/Perla (5/1/98) SEI Report - Process - Initial Survey - Selection Criteria - Interview Results - Conclusion - Appendix -- survey -- raw data Interview teams 1) Sheneui/George (1) American University 2) Neal/Jack (Nancy or Kathy as backup) (2) SEFT 3) Mike/Perla (2) TTU, CDSI ====================================================================== TEAM 2 - SE Content and Curriculum Team 2 of the Working Group is concerned with study, discussion, activities and proposals concerning two issues: - the content of the software engineering profession - software engineering curriculum design and development Participants: Don Bagert, Neal Coulter, Morven Gentleman, Jorge Diaz-Herrera, Tom Hilburn, Greg Hislop, Peter Knoke, Susan Mengel, Melody Moore, Fernando Naveda, Dale Oexmann, Erna Olislaegers, Michael Ryan, Laurie Werth The primary activity of Team 2 for the February meeting was discussion and work related to identifying and describing a set of "Guidelines for Software Education". Team activities included the following: 1. Report on previous work. 2. Discussion of the Guidelines objectives. The following objectives were agreed upon: - Promote acceptance of Software Engineering as a discipline among professionals in education and industry. - Encourage greater uniformity in software education within and across computing disciplines. - Provide a coherent, structured description of software engineering concepts, knowledge, and practices that supports software education curriculum development. - Develop a model curriculum for software engineering that can be applied in whole, or part, to the development of undergraduate programs. 3. Discussion of the body of knowledge for software engineering, relative to SE curriculum development. The Team drafted the following high-level description software engineering as a field of study: - SE Core Components Software Requirements Software Design Software Construction Software Project Management Software Evolution - SE Foundations Computing Fundamentals Human Factors Application Domains(real-time, database, intelligent systems, graphics, etc.) - Recurring Components Ethics and Professionalism Software Processes Software Quality Software Modeling Software Metrics Tools and Environments Documentation - Supporting Components General Education, Mathematics, Natural Sciences, Social Sciences, Business Studies, etc. 4. In the Wednesday (2/25/98) session of CSEET98 there was a report on the Gudielines effort. 5. Future plans of the team include: - Work will continue on the description software engineering as a field of study. As this description matures work will begin on a curriculum model, sample implementations of the model, a discussion of the necessary support for the development of software engineering curricula, and advice on assessment and accreditation. This work will also provide guidance on how to incorporate software engineering into other computing curricula. We envision that the Guidelines will support and complement the work of the IEEE-CS/ACM task force on Software Engineering Education. - Report on Guidelines work at FIE98. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Jurgen Borstler ECOOP'98 Workshop on Learning and Teaching Objects Successfully --------------------------------------------------------------- Brussels, Belgium, July 21, 1998 The goal of learning and teaching objects is to enable students/ trainees to successfully participate in an object-oriented development project. The workshop will bring together people from industry and academia to discuss approaches to object-oriented education and training. The workshop is open for discussions on all aspects related to the teaching and learning of object technology. Please check the workshop's home page for examples of topics. The main goal of the workshop is to share teaching and learning experiences in object technology. The workshop participants will identify key problem areas which will be discussed in small working groups. The workshop participants will discuss various aspects of object-oriented education and training from different points of view. We want therefore encourage not only trainers and educators to participate. We are also interested in trainees or students to report on their (learning) experiences. Furthermore we would like to hear what employers or managers want us to teach. To foster lively discussions all participants are required to submit a "top ten" list of recommendations for successful teaching and/or learning. We have planned to publish the workshop contributions and the workshop results after the conference. Submission deadline: May 1, 1998 For more information please check Organizers: Jurgen Borstler Thorsten Janning Contact: Jurgen Borstler Department of Computing Science Umea University SE-901 87 Umea, SWEDEN phone: +46 (90) 786-6735; fax: +46 (90) 786-6126 ###################################################################### From: Elisabetta Di Nitto via Don Bagert (Academic/Misc Editor) ICSE 99 Please find the ICSE99 call for papers at the following URL: http://sunset.usc.edu/icse99/ [Editor's Note: ICSE is the International Conference on Software Engineering.] ###################################################################### From: Thomas Hilburn PSP(SM) Summer Workshop for Faculty Date: June 22-26, 1998 Location: Embry-Riddle Aeronautical University, Daytona Beach, Florida Sponsors: Software Engineering Institute and Embry-Riddle Aeronautical University The workshop will provide Personal Software Process (PSP)* training for faculty who plan to use the PSP in an academic computing program (e.g., computer science, information science, software engineering, computer engineering, etc.). The PSP, developed by Watts Humphrey at the Software Engineering Institute (SEI), is designed to help students and engineers to organize and plan their work, track their performance, manage software quality, and analyze and improve their personal process. The workshop includes instruction and discussion of PSP concepts, techniques and process elements. PSP exercises and programming assignments are used to reinforce lecture topics. In addition, the workshop will provide information and guidance on how to introduce PSP into a curriculum. The PSP is proving to be an excellent way to introduce good software engineering practices into a computing curriculum and prepare students to work in an industrial setting where planning and quality are critical. Participants must be conversant with a high-level language (preferably C, C++, Ada, Java, or Pascal). Instructors Dan Burton is a senior Member of the Technical Staff in the Software Process Program at the SEI. Dan has extensive industrial experience in teaching and consulting about PSP. Tom Hilburn is a Professor of Computer Science at Embry-Riddle Aeronautical University. Tom has been a leader in efforts to integrate software engineering and the PSP into academic computing programs. Course Fee $400 for Faculty from U.S. Schools $600 for International Faculty (The fee does not cover transportation, meals or lodging.) How to Apply Apply from the Web at http://erau.db.erau.edu/~hilburn/psp or Complete the enclosed application form and send by mail or FAX to: PSP Workshop Department of Computer Science Embry-Riddle Aeronautical University Daytona Beach, FL 32114 FAX: 904-226-6678 email: hilburn@db.erau.edu Application by: May 14, 1998 Notification by: May 21, 1998 Phone or email questions about the workshop may be addressed to: phone: 904-226-6889 email: hilburn@db.erau.edu For more information on the workshop go to the World Wide Web: http://erau.db.erau.edu/~hilburn/psp *Personal Software Process and PSP are service marks of Carnegie Mellon University. -------------------------------------------------------------------- 1998 PSP* Faculty Workshop Application Form June 22-26, 1998 Last Name: __________________________ First Name: ______________ Position/Title: _____________________________ Date: ____________ Organization: ____________________________________________________ Address: ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ Phone: _______________________ FAX: _______________________ email: _______________________ Programming Language Preference: ___________________ Will bring Laptop (Y/N) _____ Lodging Preference: University Housing ____ Local Motel _____ Make own Arrangements ______ Please describe any PSP knowledge or experience that you already possess: _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ Please describe why you want to attend the workshop and what you hope get from it? _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ _____________________________________________________________ How do you see PSP fitting into your curriculum? Do you plan to incorporate it? ______________________________________________________________ ______________________________________________________________ ______________________________________________________________ Other comments: _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ Mail, FAX or email to: PSP Workshop Department of Computer Science Embry-Riddle Aeronautical University Daytona Beach, FL 32114 FAX: 904-226-6678 email: hilburn@db.erau.edu * Personal Software Process and PSP are service marks of Carnegie Mellon University ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Faculty Positions ###################################################################### From: Joe Kasser University of Maryland University College This is to invite anyone interested in part time teaching at the Master's level for program managment, systems and software development to contact me. We are looking for both classroom and distance-learning adjunct faculty, so you don't have to be here to teach here :) Joe ====================================================== Joe Kasser DSc, CM, CEng. (W3/G3ZCZ) Organizational Engineering University of Maryland University College The Excellence! Paradigm mailto:jkasser@polaris.umuc.edu office phone 301 985-4616, fax 301 985-4611 http://nova.umuc.edu/~jkasser ====================================================== ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 . 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). 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: signoff fase To rejoin (or have someone else join) the FASE mailing list, write to and, in the text of your message (not the subject line), write: subscribe fase 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 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! Send requests for information problem reports, returned mail, or other correspondence about this newsletter to 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. Back issues (from 1997 and 1998) can be found on the FASE web page . 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