Forum for Advancing Software engineering Education (FASE) Volume 11 Number 09 (Issue 140) - September 15, 2001 Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents In Memoriam This Month's Topic - Software Engineering as a Profession After the Withdrawal: One Year Later Introduction by Donald J. Bagert, Topic Editor The Guide to the SWEBOK Project: A Status Report by Robert Dupuis, Pierre Bourque and Alain Abran IEEE Computer Society Develops Competency Recognition Program by Steve Tockey Software Engineering as a Profession After the Withdrawal: One Year Later (Position Statement) by Cem Kaner Any Real Progress, or Is It Just Politics and Turf Wars? by J. Barrie Thompson Calls for Participation CSEE&T Deadline Extended Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: The FASE Staff In Memoriam As we assemble this issue, our thoughts remain on the horrific events of Tuesday, September 11 in New York, Washington DC and Pennsylvania. Our prayers go out to the families and loved ones of the victims of these terrorist acts, and to those who are working day and night even now, searching for signs of life in the rubble. You, the readership of FASE, live in over 50 countries, come from different ethnic backgrounds, and have a wide variety of religious and political beliefs. However, all of us have been affected in one way or another. Let us all hope that from this terrible act, a better, safer and more caring world will emerge. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This Month's Topic - Software Engineering as a Profession After the Withdrawal: One Year Later ###################################################################### Introduction Donald J. Bagert, Topic Editor Texas Tech University Don.Bagert@ttu.edu On 30 June 2000, ACM voted to withdraw from the Software Engineering Coordinating Committee (SWEcc or SWECC), primarily due to differences with the IEEE Computer Society (its partner in the venture) over the licensing of software engineers. That September, FASE published several articles on the topic "Software Engineering as a Profession After the Withdrawal", which provided for a wide range of articles on the subject. Currently, most of the projects coordinated by SWECC, including SWEBOK (the body of knowledge project) and SWEEP (the education project, which is still a joint IEEE-CS/ACM venture) are still existing and active. It is therefore fitting that FASE revisit the subject a year later, to see how the SWECC projects are doing, to discuss what impact the ACM withdrawal has had, and to look at the progress of other software engineering professional initiatives that may have an impact in this field. The four articles below provide a wide variety of information and viewpoints. First, the editors of SWEBOK (Robert Dupuis, Pierre Bourque and Alain Abran) provide a progress report on their project. Next, Steve Tockey reports on IEEE-CS certification efforts (which, incidentally, never involved ACM or SWECC). Cem Kaner, who is both an attorney and a computer science professor, provides a detailed article primarily focusing the issues involved in the licensing of software engineers. Finally, Barrie Thompson provides an international viewpoint of the development of software engineering as a profession. (Note: An article on SWEEP solicited for this topic has been delayed due to timing issues related to that project, and will hopefully appear in a near-future issue of FASE.) ###################################################################### The Guide to the SWEBOK Project: A Status Report Robert Dupuis Universite du Quebec a Montreal Dupuis.Robert@uqam.ca Pierre Bourque Ecole de Technologie Superieure pbourque@ele.etsmtl.ca Alain Abran Ecole de Technologie Superieure abran.alain@uqam.ca Over the past year, the Guide to the Software Engineering Body of Knowledge (SWEBOK) has moved from a development mode to a trial mode in organizations across the world. We begin by describing the major events in the project of the last year and then we give some indications on its foreseeable future. ACM Withdrawal from the Software Engineering Coordinating Committee The impact of the withdrawal of the ACM from the IEEE Computer Society/ACM Software Engineering Coordinating Committee has been very small over the last 15 months. The Guide to the SWEBOK was formally conducted under the leadership of this joint committee. The project now formally answers to the IEEE Computer Society Professional Practices Committee. After the withdrawal, the Guide to the SWEBOK project activities continued as planned including the very successful public review cycles. The ACM had a representative on the Guide to the SWEBOK's Industrial Advisory Board up to May 2000. The ACM's participation on this Board was generally very minimal. The ACM representative never brought to the attention of the Board its reasons for withdrawing from the Joint Committee nor its concerns regarding the Guide to the SWEBOK. Disposition of Cycle 3 Review Comments The major task in the project over the last year has been the disposition of the comments collected in review cycle #3 and, then the corresponding editing of version 0.95 of the Guide. The review cycle #3 was performed on version 0.7 (published in Spring of 2000). It produced over 3500 comments from 378 reviewers (70% with more than 10 years of industrial experience). These reviewers were from 41 countries, 70% of them with a master's degree or higher and only 25% declared themselves from the education field. The key target users of the Guide being the practitioners themselves, the collected reviewer demographics contributed significantly to the relevance of the reviewer comments. All comments were dealt with individually and both the comments and their disposition rationales are available on the project web site, www.swebok.org, under Search Review Results. Publication of Trial Version 0.95 In February 2001, Trial version 0.95 was posted on the project site. The previous working title for the version, "Stone Man", was replaced with "Trial Version" because it reflected much better the purpose and the level of maturity of the document (as mentioned in the September 2000 issue of FASE by Scott Duncan, for instance). The document is currently in the hands of the Computer Society Press editors for final professional proof reading and editing. Publication of a hard copy is expected to occur sometimes this fall. A free downloadable version will of course always continue to be available on www.swebok.org. Endorsements In April 2001 the project Industrial Advisory Board adopted the following motion, endorsing version 0.95 of the Guide: "The Industrial Advisory Board of the Guide to the Software Engineering Body of Knowledge (SWEBOK) project recognizes that due process was followed in the development of the Guide (Trial Version) and endorses the position that the Guide (Trial Version) is ready for field trials for a period of two years." In May 2001, the Board of Governors of the IEEE Computer Society adopted a similar motion: "the Board of Governors of the IEEE Computer Society accepts the Guide to the Software Engineering Body of Knowledge (Trial Version) as fulfilling its development requirements and is ready for field trials for a period of two years." ISO Technical Report Over the past year, the ISO subcommittee on software engineering standards (ISO/IEC JTC1/SC7) has formally begun the adoption process of the Guide to the SWEBOK as an ISO Technical Report. The process involving many steps will require many months to complete. New members of the Industrial Advisory Board The Canadian Council of Professional Engineers, Construx Software and the Mitre Corporation joined the project's Industrial Advisory Board over the past year and are providing additional funding to the project. Future Experimentation of the Guide is already underway in a number of organizations. Feedback from these field trials will provide the basis for the production of the next version of the Guide (preliminary title: Iron man version). Some university programs are being designed and reviewed using the Guide as a major input, courses are being developed around the Knowledge Areas described in the Guide, corporate professional development plans and numerous other human resources activities are built using the contents of the Guide as guidelines, etc. The project is also committed to increasing its links with other major initiatives related to the professional development of software engineering such as the IEEE SWEEP project (Software Engineering Education Project) and the IEEE Computer Society Certification project. Efforts are underway to make sure there is as much consistency as possible across SWEBOK and these two other projects. Detailed plans for the Trial phase are being worked out and will be discussed at the end of October at the annual meeting of the project's Industrial Advisory Board in Montreal. Announcements will then be made about the project deliverables and schedule. More specifically, the following issues have been identified: 1. Getting feedback from the field trials and consolidating them into "lessons learned" and recommendations for the Iron Man version; 2. Terminology synchronization with the collection of software engineering standards collection and other consensus-based documents; 3. Design of a process for the continuous updating of the Guide to SWEBOK (once the current project is completed). By the end of October, the project's Industrial Advisory Board will have approved both the general directions and the details of the planning. This also means that we will have identified more precise tasks where volunteers could help move the project forward. ###################################################################### IEEE Computer Society Develops Competency Recognition Program Steve Tockey Vice President of Consulting Construx Software 11820 Northup Way, E-210 Bellevue, WA 98005 www.construx.com The IEEE Computer Society has developed a competency recognition program for software engineers. During the development, the program was known as the Certified Software Engineering Professional (CSEP), but there are still some issues with the name and the IEEE is deciding what to do about it. Although CSEP was never part of SWEcc, it has a relationship to projects such as SWEBOK that SWEcc once coordinated. The overall certification program includes requirements on education, professional experience, passing an examination, and continuing education. To be eligible to take the exam, a candidate must have, at minimum, a bachelor's degree and 9,000 hours of software engineering experience. After passing the exam, certificate holders will be required to obtain at least 35 hours of approved continuing education over a three year period to renew their certification. The development of the competency recognition program involved hundreds of people from around the world who provided varying degrees of formal and informal contributions. The project was headed by a steering committee which was led by Don Bagert (Texas Tech University). Also on the steering committee were Dick Fairley (Oregon Graduate Institute), Jorge Diaz-Hererra (Southern Polytechnic State University) and Steve Tockey (Construx Software). Former IEEE Computer Society president Leonard Tripp (The Boeing Company) coordinated the effort with IEEE and was an active contributor throughout. Stacy Saul (IEEE) provided administrative and technical support. Linda Montgomery and Keith Sapp (The Chauncey Group International) provided professional consulting on certification test development over the project. Most of the development effort was centered on developing the examination. The project spanned a little over two years and was made up of eight discrete phases. Phase 1 was the development of a Job Analysis Survey. This survey was a list of candidate software engineering skills and knowledge. The list was designed to be put out to the industry for comment (Phase 2) where respondents would rank the skills and knowledge in terms of importance to a practicing software engineering professional. Phase 1 was conducted in April, 1999 at Oregon Graduate Institute in Portland, OR and involved 13 participants plus staff and consultants. Phase 2 involved posting the survey on the Web and collecting survey results from a cross-section of software professionals. Hundreds of responses were submitted from around the world during the Summer of 1999. Phase 3 was the development of a test specification which reflected: a) a review of the results of the job analysis study b) finalization of the listing of tasks and knowledge that were to be included in the certification examination, c) finalization of the test content percentages, and d) linkages between the knowledge and task statements to guide test development In effect, the test specification defined how many test questions were needed in what specific subject areas. Phase 4 was an item writing workshop and was held in April, 2000 in Houston, TX. During this phase, candidate exam questions were written and given a preliminary review. Approximately 600 separate candidate questions were created and reviewed by a team of about 20 participants. Phase 5 was held in July, 2000 in Seattle, WA. During this phase, another team of about 20 people gathered to do a preliminary review of the 600+ candidate test questions. Phase 6 was a final formal review of the examination itself. Time was spent on making sure the candidate questions were well-stated and that a sufficient number of questions were available in each of the subject areas defined in the test specification. This workshop was held in November, 2000 in Marietta, GA and had about 15 participants. In Phase 7 Chauncey Group International took the 600 candidate exam questions and produced the beta version of the formal test. The test was then given to 311 participants. Beta test participants took the test electronically at sites around the world. Participants came from Argentina, Brazil, Canada, China, India, Japan, Russia, Switzerland, USA, and the UK. The average age of the beta test participants was 41 and the average reported number of years of industry experience was 9.8. Of the 311 participants who took the beta version of the test, 79% earned passing scores. Phase 8 was the cut score determination. In July, 2001, A team of 8 people who were not involved in the original test development took the beta test themselves and rated each exam question for difficulty. The individual ratings were merged into a group consensus rating for each question. Using statistical analysis, The Chauney Group International produced a set of candidate "cut scores", or minimum passing scores. The steering committee used the consensus ratings from the cut score team, along with performance statistics from the beta tests to set the pass/fail score. Several problematic exam questions were also identified during the beta test phase. These questions were addressed by the steering committee and improved during the cut score phase. Anyone interested in getting more information on the recognition program should contact Stacy Saul (ssaul@computer.org) or visit the program's web site at http://computer.org/certification. ###################################################################### SOFTWARE ENGINEERING AS A PROFESSION AFTER THE WITHDRAWAL: ONE YEAR LATER Cem Kaner, J.D., Ph.D. Professor Florida Institute of Technology INTRODUCTORY CONTEXT I'm writing this article at Don Bagert's request. He asked me for an article because I participated in an ACM task force on the licensing of software engineers. This article reflects my own views only. My statements do not reflect the content or tone of the task force's discussions. My focus here is potential impact of licensing (and, to a lesser degree, certification) on members of the profession. I haven't seen much discussion of these issues and I think they're important. Some of these points were made in the ACM task force discussion, but its discussions were much broader and more focused on software safety. My treatment of these issues might be different if I was aware of convincing evidence that licensing, or SWEBOK, would improve software quality or safety. COMMON GROUND Many of my values and beliefs accord with those that I believe are shared by members of this list. For example, -- I believe it is important to foster an attitude of professionalism among software engineers. -- I am offended by the low quality and aggressive and misleading advertising of many software products. I'm senior author of a book, BAD SOFTWARE, that Ralph Nader endorsed as "a how-to book for consumer protection in the information age." I'm also the senior author of TESTING COMPUTER SOFTWARE. -- I believe that some of the deaths caused by software errors could have been prevented by the application of better software engineering practices. -- I don't object in principle to licensing professionals. I'm licensed as an attorney (member of the California State Bar) and agree strongly that it should be a licensed profession. -- I favor holding people accountable for bad acts and bad work. I served as a full-time volunteer Deputy District Attorney, putting criminals in jail in Santa Clara, California. I spent an enormous amount of my money and time fighting the Uniform Computer Information Transactions Act because I believed that it would allow vendors of defective or unsafe products to shield themselves from liability. In California, we have strong ethics rules for attorneys. It's even a crime (misdemeanor) in California for an attorney to fail to promptly return clients' phone calls. State Bar prosecutors can haul an attorney into State Bar Court for ethics violations. The attorney can be reprimanded, suspended, disbarred, or fined any amount of money. Protests led to a 1996 referendum to abolish the State Bar. Many of us believed that, after disbarment, the state's next disciplinary system would be much less aggressive. I was proud when the majority of California's attorneys voted to continue a strong, mandatory-membership State Bar. I haven't litigated any malpractice cases, but I definitely believe that individuals who commit malpractice should be held liable for malpractice. MY OBJECTIONS TO LICENSING Despite our common ground, I have several objections to licensing software engineers at this time. Here are a few of them: 1) Our profession is not currently subject to malpractice litigation. 2) Becoming licensed will transform us into a profession whose members can be sued for malpractice. 3) Calling us a licensable profession is premature because we do not have a consensus on a code of ethics. 4) Calling us a licensable profession is premature because we do not have a consensus on a body of knowledge. 5) Certification of software engineers might open certified members to malpractice suits. 6) Exposing the profession to malpractice litigation at this time will damage the profession and work injustices on working software engineers. 7) Malpractice insurance premiums will become a significant tax on members of our profession. 8) If we license only the independent software engineers, an unlicensed employee will not have the option to quit and go independent. 9) If we want to change the law to drive quality improvement, we should tie the law simply and directly to the quality of the product or service as delivered. 1) OUR PROFESSION IS NOT CURRENTLY SUBJECT TO MALPRACTICE LITIGATION The Software Engineering Code of Ethics for Professional Practice (approved by ACM and the IEEE-CS) at www.acm.org/serving/se/code.htm defines "software engineers" as "those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems." I think this is the correct definition. Note that it includes most of the software development community. One of the common definitions of a "profession" is "A vocation requiring advanced education and training" [1]. Software engineering is certainly a profession within this definition. In legal proceedings, judges will typically rely on a narrower definition when they are asked to rule whether a given vocation is a profession. Judges in such situations often evaluate a vocation in terms of the following five factors [2]: "1. a requirement (for entry into the profession) of extensive learning and training; 2. a code of ethics imposing standards above those normally tolerated in the marketplace; 3. a disciplinary system for members who breach the code; 4. a primary emphasis on social responsibility over strictly individual gain, and the corresponding duty of its members to behave as members of a disciplined and honorable profession; and 5. the prerequisite of a license prior to admission to practice." Few or none of these apply in computing. In one of the two leading treatises on computer law [3], L.J. Kutten discussed these factors as follows: "Applying these criteria to software has some startling results. "TRAINING: Education and learning in software can range from formal graduate level training in a university environment to picking up a book and reading it. Attempts at formal certification have been abysmal failures... Some of the best minds in computers have very little formal training. "CODE OF ETHICS AND SOCIAL RESPONSIBILITY: There is no formal code of ethics accepted by a majority of computer professionals. While there are a number of professional organizations, the members are not punished for violating their codes. "DISCIPLINARY SYSTEM: There is no disciplinary system for programmers that is equivalent to the system faced by lawyers, doctors, engineers and so forth. The worst that can happen to a programmer is that he or she will be expelled from a particular society. This assumes that there is an expulsion procedure. For example, while the Association for Computing Machinery has long had a code of professional conduct, it has no formal procedure for enforcement. "LICENSING: No state nor the U.S. Government requires a computer professional to be licensed." Under these criteria, software engineers could not be considered as professionals and therefore could not be sued for malpractice. In fact, lawsuits for computer malpractice almost always fail. For readers who are interested in the legal analyses, I have updated my paper, "Computer Malpractice" [4] I've found only one court decision that allowed a lawsuit for computer malpractice, it is an old decision, and later courts have declined to follow it. Another case allowed a lawsuit for ordinary negligence in the performance of computer-related services, and there is stronger theoretical support for such a suit, but later courts have rejected that approach as well. The dominant trend in American law is that if a client of a software service provider or a customer of a software development company wants to sue for defective services or products, they will have to sue for breach of contract, fraud, deceptive practices (or a similar cause of action). Negligence actions will arise only if the service provider has a special relationship of trust with the client or if the product or service has caused a physical, personal injury or damage to tangible property. Neither of those negligence actions are "professional negligence" or "malpractice." 2) BECOMING LICENSED WILL TRANSFORM US INTO A PROFESSION WHOSE MEMBERS CAN BE SUED FOR MALPRACTICE. The factors listed above guide the courts when they have to make a decision about a profession without having the benefit of a clear statement of the law by the legislature. If a state legislature or a state regulatory agency, acting within its authority, determines that software engineering is to be considered a licensed profession in that state, then that state's courts will treat software engineers like other licensed engineers, doctors and lawyers, and will allow suits against software engineers for malpractice. Even judges who ruled previously that software engineering is not a profession will change their position or the appellate court that reviews their next software engineering malpractice decision will change it for them. 3) CALLING US A LICENSABLE PROFESSION IS PREMATURE BECAUSE WE DO NOT HAVE A CONSENSUS ON A CODE OF ETHICS. The Preamble to Software Engineering Code of Ethics for Professional Practice states that "This Code expresses the consensus of the profession on ethical issues." But does it? How was this consensus established? Was there a referendum or vote of approval by the full profession? Do we have other data that shows empirically that software engineers (as defined by the Code) approve of and strive to follow it? I am skeptical that this Code expresses a consensus because the Code is routinely violated in the field and, it appears to me, it is not routinely consulted by software engineers. Nor has there been any effort by the profession to enforce the code. A code of ethics that does not guide conduct is not a professional code of ethics. Several provisions of the Code seem to be routinely violated in the field, such as Sections 1.03, 1.06, 2.07, 3, 3.01, 3.02, 3.03, 3.05, 3.08. 3.09, 3.10, 5.05, 5.07, 5.09, 5.11, 6.02, 6.03, 6.07, 6.08, 6.09, 6.10, 6.11, 8.08, and 8.09. I discuss several of these examples in "Computer Malpractice" [4]. I cannot discuss them all here because of length limitations for this paper. Here are a few examples. SECTION 1.03 "Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy, or harm the environment." How many products are shipped with hundreds or thousands of known defects, including plenty of failures to meet specs and pass appropriate tests? (In commercial and mass-market software, how few are not shipped with extensive problems?) SECTION 3.01 "Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public." These tradeoffs are often considered trade secret. The authority to decide what to disclose rests with corporate management. Working engineers would breach their employment contracts by disclosing this data to the public. I am not convinced that this breach would be ethical, and therefore I think it is inappropriate to tell the engineer that it is her DUTY to ENSURE such disclosure. I strongly favor a requirement disclosure of known defects and other results of the design and development tradeoffs, but the working engineer (or the independent consulting engineer) is the wrong target for this requirement. SECTION 3.08 "Ensure that specifications for software on which they work have been well documented, satisfy the users' requirements and have the appropriate approvals." Many projects operate from minimal levels of specification. Some of these projects fail, others succeed. Some people prefer much more detailed documentation, but I know few people who consider light specifications _unethical_. SECTION 3.09 "Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." I agree that it is good practice to suggest realistic estimates and protest absurd ones. However, I don't see an ethical obligation ON AN EMPLOYEE OR CONSULTANT to ***ENSURE*** that these estimates are realistic. Many companies' senior managers reject realistic estimates. That does not make the staff of those managers unethical. Finally, SECTION 3.10 "Ensure adequate testing, debugging, and review of software and related documents on which they work." This statement is so far removed from actual consensus that it is inconsistent even with the conduct of the ACM and the IEEE-CS. The ACM / IEEE Curriculum Guides heavily influence the design of undergraduate Computer Science degree programs. The amount of required study of testing techniques is trivial -- a few hours over four years. The 1991 Computer Science curriculum guide suggests one optional course, Advanced Software Engineering, that includes testing topics among many others, but the guide doesn't even mention the idea of a course focused on software testing. The 2001 Guide is not significantly improved in this respect. If the professional societies determine that software development students need not be well trained in testing, then directives to "ensure adequate testing" are hollow. 4) CALLING US A LICENSABLE PROFESSION IS PREMATURE BECAUSE WE DO NOT HAVE CONSENSUS ON A BODY OF KNOWLEDGE. A shared body of knowledge is important. It is the essence of the education requirement: we expect professionals to share a certain foundation. Each member of the profession builds up from that foundation. If there is a malpractice suit, the people who will decide whether an engineer committed malpractice will not be engineers. The jury and judge, the lawyers, and the engineer's malpractice insurance company will look to the accepted body of knowledge for help to determine whether a professional's work fell below the minimum standards of knowledge, skill and diligence in the field. The SWEBOK describes itself as a normative document and as presenting the consensus of the profession. My understanding is that it will be put forth as a body of knowledge basis for developing a licensing exam for software engineers. In a world that licenses software engineers, this will be a very influential document. James Bach, Bret Pettichord and I made several specific criticisms of the SWEBOK, as it applies to software testing, in our forthcoming book, LESSONS LEARNED IN SOFTWARE TESTING (Wiley, 2001). I will summarize one criticism from that book here, to illustrate the problems. The SWEBOK unconditionally endorses the IEEE Standard 829 for software test documentation. Standard 829 itself, and the SWEBOK endorsement of it, carry no context, no indication of when it would be useful or desirable and when not. It is a solution for all projects. We are not aware of scientific research that demonstrates that Standard 829 is a good method, or a better method than others, or desirable under studied circumstances. We have seen no controlled experiments, no causal models, no theoretical derivation. If engineering involves the application of proven scientific knowledge to practical situations, where is the science underlying Standard 829? Standard 829 appears to be outside of the scope of engineering. What place does it have in an Engineering Body of Knowledge as a recommended practice? Standard 829 is in the Body of Knowledge because it won a popularity contest--it was endorsed (or not strongly enough opposed) by the authors of SWEBOK and those relatively few people (fewer than 500 total, and those subject to no screening for qualifications, if we understand the statements on the SWEBOK website correctly) who chose to participate in the SWEBOK drafting and review process so far. Our perception, based on experience with many commercial software developers, is that while we respect the care and thinking behind Standard 829, we think it has done more harm than good in commercial software. Whether we would recommend it to our clients depends on their specific circumstances. In many cases, we would not. What is the consequence? A software engineer who recommends against the use of Standard 829 puts herself at risk. If the project fails and she is named in a malpractice lawsuit, her recommendation against following a standard that is endorsed in the Body of Knowledge will be used as a bludgeon against her in court. Even if she made the right decision, the jury, the judge, the lawyers, the insurance companies and the press will be more likely to trust the Body of Knowledge than the contrary judgment of an engineer being sued for bad judgment. An official Body of Knowledge creates an orthodoxy that we do not have today. If the orthodox practices are not well founded in science, as so much of SWEBOK seems not to be, the evolution of the field from weak (but orthodox) practices to better ones will be the subject of lawsuit after lawsuit. And the results of those suits will be determined by non-engineers who don't understand the practices. Without a broad agreement on the field's Body of Knowledge, I think that the decision to throw our field's development into the arms of lawyers is unwise in the extreme. As a final comment on the SWEBOK, I note the critique published at the Association for Computing Machinery's web site, www.acm.org/serving/se_policy/bok_assessment.pdf ("An Assessment of Software Engineering Body of Knowledge Efforts") and the ACM's withdrawal from the SWECC, which is drafting the SWEBOK. When the field's largest professional society publishes a sharp criticism of SWEBOK and withdraws from the drafting effort, any claim that the SWEBOK represents a consensus of the field seems incredible. 5) CERTIFICATION OF SOFTWARE ENGINEERS MIGHT OPEN CERTIFIED MEMBERS TO MALPRACTICE SUITS. Even if we don't go down the licensing route, and the courts don't recognize software engineering as a profession subject to malpractice liability, some courts might entertain a malpractice or negligence suit against an individual engineer. If an engineer represents himself to the public (i.e. to clients) in a manner that makes him looks too much like a professional engineer, the courts might treat him as if he was an engineer. Jankowski [6] lists questions that would be useful to a lawyer trying to prove to a court that a software engineer is or is not a professional (someone who can be sued for malpractice): "Did the computer consultant exercise independent judgment and advise the client in connection with the computer system that was designed, developed and/or installed? "Did the computer consultant obtain specialized training such as a Masters in Information Systems from a recognized university? "Is the computer consultant certified by an organization such as the Institute for Certification of Computer Professionals ('ICCP')? "Does the computer consultant belong to an association such as the Association of Data Processing Service Organization ('ADAPSO') or the Association for Computer Machinery ('ACM') that has a code of ethics? "Does the computer consultant have malpractice insurance? "An affirmative answer to one or more of these questions will help to establish that a computer consultant is a professional. Conversely, negative answers to one or more of these questions, coupled with the present lack of licensure that applies to the computer industry, will help to establish that a computer consultant is not a bona fide professional." If the IEEE Computer Society, a large professional society with a code of ethics, approves SWEBOK and certifies software engineers on the basis of it, a certified engineer who advertises his certificate might be much easier to sue for malpractice than someone who is not certified. I discussed this in more detail, focusing on ASQ's Quality Engineer certification in [4]. 6) EXPOSING THE PROFESSION TO MALPRACTICE LITIGATION AT THIS TIME WILL DAMAGE THE PROFESSION AND WORK INJUSTICES ON WORKING SOFTWARE ENGINEERS. Standards for software engineering, including the IEEE Standards and SWEBOK, are not tightly linked to empirical evidence and other scientific research. In the context of a licensed profession, the existence of these standards, puts professionals at risk. To non-engineers, they will look authoritative even though they are based on consensus of standards-writers rather than being tightly linked to scientific research. The process of determining that an act constitutes malpractice is only partially driven by engineers. In a typical lawsuit for malpractice, an injured or economically harmed person sues the engineer, often as part of a broader lawsuit. The person brings evidence that the engineer acted in ways, or made decisions, that were not up to the professional standards of software engineering. This evidence will be evaluated by lawyers, liability insurance company staff and lawyers, jurors, and judges. None of these people are engineers. If juries find that certain conduct is negligent, malpractice insurers will probably advise their insureds (engineers) against engaging in that conduct and may well provide incentives, in the form of lower insurance rates, for engineers who adopt recommended practices or who do not engage in counter-recommended practices. Over time, the determination of what constitute good engineering practices may be driven more by the courts and insurance companies than by engineers. Over the past 30 years, American juries were required to evaluate a wide range of engineering design issues in products liability suits. This caused enormous problems. Eventually, it led to major changes in the law, resulting in the adoption of a new Restatement of Products Liability that completely redefined the standards for holding a manufacturer accountable for a product's design defect. [7] Why should we want to subject our profession to problems like these? 7) MALPRACTICE INSURANCE PREMIUMS WILL BECOME A SIGNIFICANT TAX ON MEMBERS OF OUR PROFESSION. In the face of uncertain standards, once malpractice liability is created and applied to software engineers, every software engineer would be wise to buy insurance. At the moment, software engineers can buy malpractice insurance for as little as $495 per year (see one such policy's details at www.acmpro.com.) But after several engineers are successfully sued, premiums will go up. In other professions (such as some specialties in medicine), malpractice premiums run as high as $50,000. If we add significant costs to the practice of software engineering, the character of the field will change as its practitioners find that they MUST earn a lot of money just to stay in the field. For example, - How will that affect the pool of people who are willing to donate their time to the development of free software or to work on other social responsibility projects? - How will it affect our ability to create start-ups, which are often run on bare subsistence wages during their earliest phases? - How will it be possible for a software engineer to afford to quit his job and become an independent contractor or consultant? 8) IF WE LICENSE ONLY THE INDEPENDENT SOFTWARE ENGINEERS, AN UNLICENSED EMPLOYEE WILL NOT HAVE THE OPTION TO QUIT AND GO INDEPENDENT. Software engineers have job mobility. If you are laid off, or you quit, you can look for a new full-time job or you can work as an independent contractor or you can open a business as an independent consultant. Especially when times are tough, many engineers who lose their jobs set themselves up as independent contractors or consultants so that they can earn some income while they look for full-time work. If full-time employees don't have to be licensed, but independents do, we create a two-class system that doesn't exist today. The employee who loses her job (but isn't licensed) can't become an independent until she gets her license (which will take time). 9) IF WE WANT TO CHANGE THE LAW TO DRIVE QUALITY IMPROVEMENT, WE SHOULD TIE THE LAW SIMPLY AND DIRECTLY TO THE QUALITY OF THE PRODUCT OR SERVICE AS DELIVERED. Software development is done by groups of people. Key decisions are made by executives who are often not software engineers. The most direct way to change their decisions, is to change the law so that it holds those companies and their executives accountable. Suing an independent engineer for malpractice is a very indirect way of introducing accountability. First, I think it penalizes the wrong person. The development company will pay more attention when its own profits and managers are at risk. Second, to prove malpractice, you don't just have to prove that the product was defective or unreasonably dangerous. You also have to prove that the independent engineer was negligent. Here are a few examples of changes to the laws governing software sales and licenses that would have a direct impact on software quality: a) The maker and vendor of a software product should be required to reveal all of the defects that they know about in that product, and to document them in a way that a typical member of the market for that product can be reasonably expected to understand. b) Clauses in software licenses that restrict reverse engineering should be unenforceable against reverse engineering done for the purpose of discovery or proof of safety or security related problems. c) Clauses in software license that restrict publication of benchmark studies or other product reviews should be unenforceable against revelation of safety or security related problems. d) The customer of a software product, including software embedded in a device, should be able to see the terms of the software license before incurring an obligation to pay for the product. e) If a software product, including software embedded in a device, is the cause of an injury to a person or to damage to physical property, the terms in the license should not be enforced if they (i) select the law of a state that is neither the state in which the injured party lives or the state in which the injury took place, (ii) require the injured person to travel to another state, or (iii) limit damages below those that would normally available in a products liability suit. I've been told that licensing is a better approach because it is politically impossible to get laws like this passed. Maybe, this year, that's true. However, if the software professional societies spoke consistently and loudly about these matters, public interest in these proposals would probably rise steadily. As an additional point to think about, if software and computer vendors can block laws like these, they can block laws for licensing software engineers. If they choose not to do so, what does that tell us about the expected efficacy of those laws? NOTES [1] Black's Law Dictionary [2] K.S. MacKinnon, "Computer malpractice: Are computer manufacturers, service bureaus, and programmers really the professionals they claim to be?" Santa Clara Law Review, Volume 23, p. 1065, 1983 quoted these (on p. 1078) as part of an argument favoring application of malpractice rules to software professionals. E.B. Galler, "Contracting problems in the computer industry: Should computer specialists be subjected to malpractice liability" Insurance Counsel Journal, October, 1983, p. 574 worked through the same characteristics on the other side of the argument. [3] Computer Software: Protection / Liability / Law / Forms, Volume 2, West Publishing, (Updated to Release #27, April 2001), Section 10.04[4][f] [4] Cem Kaner (2001), Computer Malpractice, www.kaner.com/pdfs/Malprac.pdf. [5] news.cnet.com/news/0-1007-201-6375299-0.html, accessed 9/6/01. [6] Gretchen L. Jankowski (2001), Computer Malpractice Actions: Are They the Wave of the Future? (www.bipc.com/articles/compmalp.htm) [7] American Law Institute, Restatement of the Law Third, Torts: Products Liability, 1998. ###################################################################### Any Real Progress, or Is It Just Politics and Turf Wars? J. Barrie Thompson Professor in Applied Software Engineering University of Sunderland, UK barrie.thompson@sunderland.ac.uk Last September I wrote on the withdrawal of ACM from the Software Engineering Coordinating Committee (SWECC) and suggested it was "time to go back and think again". I am not sure whether this has really happened as there still seems to be a clear level of disarray on one side of the Atlantic. Nevertheless, the following three sections give some personal observations which are intended to be from an international perspective, though I admit they are not totally unbiased. In these three sections I wish to consider: (i) activities associated with SWECC, (ii) activities at an international level associated with promoting and analysing proposals in a document entitled "Harmonisation of Professional Standards" which has been produced under the auspices of the International Federation of Information Processing (IFIP) and which reference was also made to this in last year's letter, (iii) suggestions as to how to progress the Software Engineering (SE) professionalism issue in the future. 1. SWECC Promoted Activities It is now more than a year since ACM withdrew but it is still very clear in talking to groups at international conferences that there are fundamental differences in views between particular members of the two societies on SE professionalism. The real difficulties are obviously associated with the Texas model for licensing software engineers and it is really unfortunate that the SWEBOK project is viewed by many (perhaps wrongly) as being inextricably linked to the Texas actions. There did appear to be some mending of fences during the panel session on SWEBOK at ICSE2001, however, the real test will be to see how much SWEBOK is really used. At the same conference it was rumoured that Dave Parnas had suggested that SWEBOK should be burnt; such statements if they happened and the resultant rumours do not help matters - they only fuel the rift. SWEBOK is not perfect (but then in SE what is?) but it does represent a significant piece of work that should be built on rather than ignored or thrown away. Perhaps it is really politics (with a small p) that has affected this project. One question that I believe needs to be answered by those involved in the SWEEC promoted projects is: Why has the project, led by Don Gotterbarn et al, concerned with defining a Software Engineering Code of Ethics and Professional Practice received such approval and been accepted by bodies outside the US while SWEBOK has led to such controversy? 2. SE Professionalism: A World Dimension In 1998 a small working party within IFIP produced a draft document entitled "Harmonisation of Professional Standards" which was concerned with setting out an international standard for professional practice in information technology. The draft standard was presented in August 1999 at the overall TC3 committee meeting in Irvine, USA and at the TC3 WG3.4 seminar held in Baltimore. (TC3 is technical Committee 3 which is concerned with education. WG 3.4 is the Working Group within TC3 which is concerned with professional and vocational education and training in information technology, and in this group I currently hold the position of vice chair). At IFIP's World Computer congress held in Beijing in August 2000 the harmonisation project was re-considered within TC3 and it was decided to refer the document back to WG3.4 for further work to be undertaken on it. It appeared to me that to try and achieve a harmonisation of professional standards in the whole of information technology was perhaps a step to far. However, I felt that the IFIP document could prove to be very useful when considering SE professionalism and that this ought to have an international dimension. Therefore, with the help of my colleague Prof. Helen Edwards I have undertaken a number of activities associated with promoting the IFIP document and analysing its relevance to SE. The major of these activities have been: A paper detailing it along with a copy of the document itself was presented at the 2000 Computer Software and Applications Conference (COMPSAC 2000) which was held in Taipei in October 2000. * It was also used as the focus for a panel session at the same conference. * It was outlined in a paper presented at the British Computer Society supported conference "Quality and Software Development: Teaching and Training Issues"; held in London in September 2000. * A half day workshop was held at the 2001 Conference on Software Engineering Education and Training (CSEE&T) in Charlotte, North Carolina in February 2001, the detailed results of which will appear in the journal Education and Information Technologies, issue 6/4 in December 2001. * A full day workshop was held during the 2001 International Conference on Software Engineering (ICSE) in Toronto in May 2001. A report on this is due to appear in ACM SIGSOFT Software Engineering Notes. * A paper concerning it was presented at the conference ETHICOMP 2001 held in Gdansk, Poland in June 2001. * Several presentations have been made relating to the document during the last few weeks in Australia. This included an invited presentation at the 2001 Australian Software Engineering Conference held in Canberra in August 2001. Generally the response to the IFIP document has been favourable with regard to it being seen as a framework. But it is recognised that it needs much more work at a detailed level. However, these activities listed above have not just been concerned with the IFIP document. Many have also enabled a wider view to be taken of issues associated with SE professionalism. In particular the CSEET workshop was very fruitful. Not only was the IFIP document critically appraised but the groups at the workshop also considered the drivers and constraints regarding professionalism in their areas of expertise and also future goals and strategies for achieving a recognised SE profession. With regard to drivers the emergent themes were: * Issues of safety and security and the need for some projects to have guaranteed "due diligence", for instance in safety-critical systems work. * Distinguishing between groups of practitioners, aiming for true professional status. * Public perception of a professional as someone who is adequately trained, practising, bound by a code of ethics, and accountable. * The need for harmonisation. The common constraints were: * The need for an accepted body of knowledge. * Practitioners do not feel a strong need to get organised since there is a skills shortage and plenty of work for those with computing skills. * There is an unmanageable diversity of standards, characteristics of certification and licensing schemes differ internationally. The final views of the workshop participants with regard to moving forward were: "Perhaps instead of looking for a consistent view of the software engineering profession across state, province and national boundaries we should explicitly articulate these different viewpoints and then determine if there is any commonality between them. Since engineers are pragmatic by nature perhaps we should start by seeking harmonisation for one small element and then building from there." "Perhaps what we should aim for is for individual countries' computer societies to identify what they think needs to be in a curriculum and to be the requirements for professional practice, then bring these together and look for commonality. There is a need to compare and contrast different international approaches, perhaps this can be done through the IFIP proposals." 3. My views on how to progress the Software Engineering (SE) professionalism issue in the future. (a) We need to move forward by analysing what has been done, identify the successes and failures and more importantly why these have occurred (engineers do not keep inventing new wheels, mostly they continually appraise what has been done before and then improve on it). (b) Try and build up a truly international view and be sensitive to local situations. In particular I believe that many of those who have been involved in the IEEE-CS and ACM projects need to be much more sensitive to international issues. I do detect movements in this area over the last year - but as yet it has not gone far enough. As I have said many times in the past, both societies claim to be international and that is partly why they have special status in IFIP, ie they are both member organisations. But time and again I perceive that this "internationalisation" is simply not the case. Having a token Brit or European or Aussie on a committee does not make it international. Similarly always presenting themselves as "top poppies" is likely to lead to resentment and alienation. Recently I attended the sessions on the Computer Science volume of CC2000 at the World Conference on Computers in Education (WCCE2001). I was not the only one to feel that what was presented had a clear US bias. (c) Get accurate data and find out what the situation is across the world both in the areas of professional practice and educational structures. Inaccurate data is actually worse than none at all. For example, at ICSE 2001 a paper was presented on an international web based survey of SE programmes in universities which had been undertaken as part of a joint ACM/IEEE-CS project. It was reported that the survey showed that there were 94 academic programs in SE in place at 60 universities. The graphs presented further indicated that the majority of the programs were in the US. This is a somewhat surprising result as it has been generally recognised for some time that there are relatively few SE academic programs in the US compared to the rest of the world. Did the authors not suspect the validity of their results? Did they not think that there had perhaps been some bias in how the survey was conducted? Did they not cross check with other sources of publicly available data? Unfortunately not. For information, a few minutes spent interrogating the UCAS web site (http://www.ucas.co.uk), which supports the Universities and Colleges Admissions Service for the UK and which hold details of undergraduate academic programs in the UK, showed that as at September 7th 2001 in the UK there were 131 SE academic programmes with SE as a single subject and 416 where SE was linked with another subject. For example, apparently at Oxford Brooks University a student could (theoretically) take a degree in Software Engineering/Water Management. However, I recognise that this information (though accurate) is also useless if one does not understand the University and educational systems in the UK. To make it more complex there are two systems as Scotland has its own. Hence there is a need not only to provide the data but also details of the context so it can be understood and compared with other data sets and information sources. (d) I recognise that things have moved on somewhat and I apologise for going on about the US but I have great concerns that we may see a model promoted for SE professionalism that is primarily centred on industry structures and educational models that reflect the situation in North America. For a discipline that will shape the 21st century a much broader view is needed. (e) What has also become very clear from the discussions during or following sessions concerned with the IFIP proposals is that the "turf wars" and tensions within US universities with regard to SE are acting as major constraints in the development of the discipline and profession. In particular these relate to issues associated with the numbers of SE and Computer Science faculty (staff) in the academic institutions. It also appears that intellectual turf wars regarding SE continue between ACM and IEEE-CS especially over SWEBOK and I wonder which SE body of knowledge will be used in the SE volume of CC2001? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Tim Lethbridge [Editor's Note: Dr. Lethbridge is the Program Chair for the 2002 Conference on Software Engineering Education and Training (CSEE&T)] Due to the events in the US, I have extended the final deadline for CSEE&T submissions until Sept 27th, although I am asking people to notify me. The extended deadline is reflected on our web site: http://www.site.uottawa.ca/cseet2002/ [under "Call for Papers"] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE FASE is published on the 15th of each month by the FASE staff. Article and Faculty Ad Submission Guidelines Send newsletter articles to one of the editors, preferably by category: Articles pertinent to academic education to Tom Hilburn ; corporate and government training to David Carter ; professional issues, faculty ads, and all other categories, to Don Bagert . If the article is for a FASE topic where there is a guest editor, the submission should instead be to that person, according to the schedule provided. 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 trailing blanks and 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). All articles contain the viewpoints of their respective authors, and do not necessarily reflect the opinions of the FASE staff. _____ Subscribe/Unsubscribe Information Everyone that is receiving this by email is on the FASE mailing list. If you wish to leave this list, send a message to and, in the text of your message (not the subject line), write: unsubscribe fase To rejoin (or have someone else join) the FASE mailing list, write to and, in the text of your message (not the subject line), write: subscribe fase For instance, if your name is Jane Smith, write: subscribe fase Jane Smith But what if you have something that you want to share with everyone else, before the next issue? For more real-time discussion, there is the FASE-TALK discussion list. It is our hope that it will be to FASE readers what the SIGCSE.members listserv is to that group. (For those of you that don't know, SIGCSE is the ACM Special Interest Group on Computer Science Education.) To subscribe to the FASE-TALK list, write to and, in the text of your message (not the subject line), write: subscribe fase-talk For instance, if your name is Jane Smith, write: subscribe fase-talk Jane Smith Please try to limit FASE-TALK to discussion items related to software engineering education, training and professional issues; 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. As always, there is no cost for subscribing to either FASE or FASE-TALK! (Subscriptions can also be maintained through the Web via http://lyris.acs.ttu.edu. From there, click on "TTU Faculty Mailing Lists", and then either "fase" or "fase-talk", depending on which list you desire.) _____ Back issues (dating from the very first issue) can be found on the web (with each Table of Contents) at in chronological order, or in reverse order. _____ The FASE Staff: Tom Hilburn -- Academic Editor Embry-Riddle Aeronautical University Department of Computing and Mathematics Daytona Beach FL 32114 USA Phone: 904-226-6889 Fax: 904-226-6678 Email: hilburn@db.erau.edu URL: http://faculty.erau.edu/hilburn/ David Carter -- Corporate/Government Editor 807 Hwy 1204 #B-2 Pineville LA 71360 Phone: 318-641-0824 Email: dacarter@bayou.com Don Bagert, P.E. -- Professional Issues/Misc Editor and Web/Listmaster Department of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: Don.Bagert@ttu.edu URL: http://www.cs.ttu.edu/faculty/bagert.html 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