Forum for Advancing Software engineering Education (FASE) Volume 10 Number 07 (126th Issue) - July 15, 2000 949 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Letter From the Professional Issues Editor: SWEcc This Month's Topic: Relevance of Mathematics in SE Education September 2000 Topic: SE as a Profession After the Withdrawal News Items ACM Withdraws from SWEcc Statements Regarding ACM's Withdrawal ACM Body of Knowledge Task Force Report Released Draft Report of Task Force on Licensing of Software Engineers Working on Safety-Critical Software Released Licensing Workshop at CRA Department Chair Conference Wulf Expresses Concern Regarding Software Engineering Ethics Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert Letter From the Professional Issues Editor: SWEcc Several articles under "News Items" in this issue concern ACM's withdrawal from the Software Engineering Coordinating Committee (SWEcc). The software engineering professional issues related to this withdrawal is and likely will continue to be a topic of great interest for some time to come. So, on behalf of the FASE staff, I would like to state our position on the subject, and also provide some insight on our editorial policy. 1. FASE is neutral on the issues related to ACM's withdrawal from SWEcc. In general, our editorial policy is to stay neutral on all such subjects. If members of the FASE staff make statements in other venues (including the FASE-TALK discussion list) concerning topics related to software engineering education, training and professional issues, they do not reflect the position of this publication. 2. As always, it is the intention of the FASE staff to provide unbiased reporting on this story, providing facts that we feel will be of interest to our readership in a way that will help their understanding of the subject. This includes publishing viewpoint statements from a wide variety of people who can provide a wide variety of perspectives. However, no anonymous or "name withheld by request" statements, nor any viewpoints being written (to our knowledge) under pseudonyms will be accepted for publication. 3. FASE is and always has been an independent publishing entity, not associated with ACM, IEEE-CS or any other organization. Information about FASE's creation and its publishing history can be found in the May 1999 issue. If you have any questions, please contact me, or any other member of the FASE staff (see end of each issue for contact information). Thanks as always for your support of FASE. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Peter B. Henderson This Month's Topic Relevance of Mathematics in Software Engineering Education Peter B. Henderson Butler University Indianapolis, IN phenders@butler.edu Regarding the survey I posted in the July issue, there were 18 responses - 12 from academia and 6 from industry. In response to the question: "Mathematics (logic, discrete math) and mathematical thinking are important in software engineering education." 73% Strongly Agree 11% Agree 5% Neutral 11% Disagree 0% Strongly Disagree Here is a survey of some of the comments. _____ "Too much of a mathematical perspective can make learning SE more difficult, but no mathematical awareness is also a serious shortcoming." _____ "But I think Vertical Thinking habits should be inculcated into software professionals. This should in the way in which it is taught as part of Philosophy. Mathematics can be taught to the extent of enabling this. I would like to differentiate between Mathematical thinking and Logical thinking." _____ "... a winner of the "best limerick" award at the recent ICSE: A coder of software was glad For the "engineer" title he had. But he'd learned just to hack, Not to think, choose, or track. So the client's big startup went bad :-( "Sure, you can teach programming without the tools needed for understanding and analysis. You can teach programming without thinking, as well. But the difference between an engineer and a tinkerer is the engineer's mental toolbox of systematic ways to understand a problem and work deliberately toward an effective solution. Mathematics, especially logic and discrete math, is part of the software engineers' mental toolbox, and it underlies some of the other tools as well." _____ "I have had my eyes opened in the last few years after more than 35 years of software development. I now have some small understanding of what Dr. Harlan Mills and others knew 20 or more years ago. There seems to be a ceiling for productivity and defect ratios for the average software engineer. The principal cause is the failure to understand the number of combinations of sequences of stimuli and state (all the state transitions) and the failure to examine rigorously and formally all combinations before going to code. I knew programs were complex but had not appreciated that complexity and my own human intellectual limitations in determining all of the state transitions as well as not being able to juggle all the variables in a given path in my head. Once you reach that epiphany, hopefully through proper mathematical study as part of a software engineering curriculum, one would understand the need to apply mathematics and formal processes ... " _____ "The problem with the question is that it bundles 'mathematics' together with 'mathematical thinking'. I believe that mathematical thinking habits are useful for many disciplines and especially for SE. On the other hand, it is hard to argue that 'software engineers need X', where X is any particular topic such as calculus, linear algebra, logic, set theory, or graph theory. As Tim Lethbridge has clearly demonstrated, practitioners do not perceive these specific topics as being useful components of a university curriculum. "By 'mathematical thinking habits', I mean the ability to make things simple (but not too simple) rather than complicated, and to know how to do this by abstraction, formalization, etc. It is no accident that the basic data structures used by programmers are the same as the basic abstractions that pervade mathematics (sets, functions, relations, graphs). 'Mathematical thinking habits' also include precise reasoning and, when appropriate, proof. To a mathematician, a proof of a theorem is not a formal exercise but rather a piece of clear and precise reasoning that provides insight into the meaning and significance of the theorem. A SE should be able to 'prove', in this sense, the validity of a design, the choice of an algorithm, etc. "The great contribution of mathematics is to show that problems that initially seem to be unrelated have an underlying common structure. Mathematicians are the ranking experts in software reuse although their 'software' comes in the form of differential equations, algebraic structures, etc. Engineering programs have recognized this and include introductory courses in general mathematical techniques that apply to many different kinds of engineering. Although an SE program should include discrete mathematics as well as some continuous mathematics, the important thing is the underlying mathematical discipline rather than the particular topics." _____ "Discrete math forms the basis for software engineering. It is analogous to calculus and physics. Without basic knowledge of calculus, a physicist wouldn't be much good. Likewise for the software engineer. Formal specifications, testing procedures, behavioral models, and obviously programming are all based in set theory, function theory, combinatorics, statistics, and logic." _____ "I have been a software developer for over 30 years. There are countless times when my mathematical training has helped me do my job better. A recent example is a case where an algorithm was simply too complex to be performed with available computing resources in the time required. By using a blend of computing and mathematical knowledge along with mathematical reasoning I reduced the complexity of the algorithm and made it work. "I have colleagues in an IT organization who periodically correlate the backgrounds of their employees (not doing scientific computing) with their backgrounds and find that those with strong math backgrounds are the best. "I also hire many software developers and find that those lacking strong math backgrounds tend to be more likely to fail at intricate programming tasks. Some do quite well at other tasks, but their value is more restricted." _____ "Mathematically based software development methods (featuring specification, refinement, and proof) are key for the successful development of certain kinds of application: for example, for safety-critical, economy-critical, and security critical systems. To support the ability of software practitioners to develop such systems, the curriculum should include appropriate mathematics and formal methods modules. "However, many systems, it would seem, are not such critical systems, and do not require such precise methods of construction. Instead they can be created by, for example, composing software components to meet requirements and then fine-tuning the result. Practitioners whose careers will be largely devoted to developing such systems do not have such a strong need for knowledge of mathematics and formal methods." _____ "Math, especially logic, trains brain in thinking that is essential in software engineering. Program solution is, after all, a precise formula. You need apply logical thinking to arrive at program solution from requirements. Elements of logic are useful in documenting programs. I do not know too many people who claim that math is irrelevant to software engineering. It is rather the question of too what extent it is relevant and what kind of math." _____ "I agree in part. Logic does not necessarily teach someone how to think in general, but only to think 'logically'. And part of the reasoning needed for SE is not be logical at all. For example, in eliciting requirements from the user and building use cases, it is much more helpful to be gentle and kind than logical!!! But I agree that logic and discrete mathematics provide much maturity to the students, and that helps a lot!!!" -------- END EXCERPTS FROM COMMENTS ------------ Unfortunately the sample size is very small and it is hard to determine how meaningful these results are. I was hoping for strong positive support from industry. The fields of computer science and even more so software engineering are very young and immature. Accordingly, these fields don't yet have a professional identity, like other sciences and engineering disciplines. The issue of what distinguishes software engineering from computer science is still under debate. My personal perspective is that software engineering is more rigorous/disciplined/professional and that the mathematical underpinning, as required by other engineering disciplines, is one of the primary distinctions between SE and CS. Undergraduate software engineering programs are beginning to spring up. One question is, in time will SE supplant CS as the desired professional program? Attached is an article by Bob Glass to appear in IEEE Software which provides a negative view of the relative importance of mathematics and mathematical thinking for the practicing software engineer. Hopefully this will help to excite some flames. For another perspective, see the home page for the math-thinking group with links to interesting papers and studies: http://www.cs.geneseo.edu/~baldwin/math-thinking I hope you have found this information useful and thought provoking. Peter B. Henderson Department of Computer Science (soon to be renamed CS and SE) Butler University Indianapolis, IN ----------------------------- "How Important is Mathematics to the Software Practitioner?" by Robert L. Glass How important is mathematics to the software practitioner? My guess is that you already have a deeply-felt answer to that question. My guess further is that your answer - whatever it is - is one you would support vigorously. I also believe that, if we were to poll the readers of IEEE Software, the findings on this question would be strongly bi-polar - on a scale of 1-7, lots of 1s and lots of 7s. In other words, I think this question is a watershed one. Lots of people believe that math is vital to the practitioner. Others believe it is of little consequence. Why do I believe that? Because of the evidence I get, as the editor of the Journal of Systems and Software, across my transom from academic systems and software people. Because of my own practical experiences, and my contacts with other practitioners. Academics, I would assert, are largely in the "math is vital" camp. Practitioners, I would further assert, are in the "math is of little consequence camp." Let me give you some examples. More than one academic, writing for an academic audience, has said, in a professional paper, "computer programs are mathematical objects" (e.g., [Young 1999]). More than one academic has said we should "improve the software engineering discipline by ... basing [it] firmly on logic and mathematics" (e.g., [Broy 1999]). Practitioners, busy as they are building software to impossible schedules, are less vocal on the topic. They tend to vote with their feet and with their minds, resulting in little or no penetration of mathematically-based concepts into the practitioner's bag of tricks. Academics are the ones who actually articulate the de facto practitioner position, saying things like "There is a remarkable discrepancy between the practice of software engineering and the theoretical ... the amount of application of [mathematically-based research] results is not satisfactory" [Broy 1999]. I addressed the practitioner position in my own essay, [Glass 1995], saying things like "If these mathematics-based [approaches] ... are truly important to the field, then it is in some ... application of software that I have not yet encountered." What's at stake here? Plenty. Computer science (and, to a lesser extent, software engineering) academic curricula tend to be math, formal-methods focused. Academic arguments for future research in the software field are often based on mathematical foundations. The federal government is told that math is essential to the (research and practice) future of the field. There's a general belief in academe that things based on mathematics are purer and better than those that are not. (Do you remember back to the point in time when we justified the structured approaches on the grounds that they were based on mathematical foundations? In the minds of (at least some) academics, the structured methods were better than their alternatives because there was math involved in their justification). In essence, academe is moving full speed ahead with their belief in math's importance to the field. In both pedagogy and research, that belief is repeatedly broadcast to the field. Note that, in the [Broy 1999] quote above, there was a judgment that the penetration of mathematically-based concepts into practice was "not satisfactory" - implying that practice was wrong in not moving itself in a mathematical direction. Isn't that a premature judgment? On what basis, exactly, are academics reaching the conclusion that math is vital to the field? Isn't this an issue that should be resolved by research? Shouldn't the true research-focused academic be interested in finding out whether mathematics is important to software's practice, rather than assuming it is and trying to force its use on practitioners? I appreciate that academics are bright people who have immersed themselves into mathematically-based approaches for decades now. I can appreciate that their analysis has convinced them that mathematics is a better way. I can appreciate how deeply they hold that belief. But the scientific method has convinced most of us that, over the passage of time, deeply-held beliefs can be incorrect. Isn't it incumbent upon academics to hold back a little, to acknowledge that our knowledge of the interaction of mathematics and software practice is still incomplete, that we might yet learn that mathematics is not as essential to the field as we have thought? Certainly, that's a good "loyal opposition" position at this point in the history of the field. I am pleased to report, in this column, that one academic researcher has at last chosen to study this very issue. And the light he sheds on it is, in some ways, profound. In [Lethbridge 2000], the author makes a study of the difference between what is taught software engineers in academe, and the perceptions of practitioners on what is important to them. The findings are fascinating. There are plenty of topics discussed in the paper; Lethbridge was not solely interested in the role of mathematics. But the most striking finding of his research was the "stark contrast" between the frequency with which mathematical topics are taught to students, and the importance those students later place on them when they emerge from their institutions and join practice. What mathematical topics? Here are the topics that the author found to be "learned most in their formal education" (note that most, although not all, of them are mathematical): 1. specific programming languages 2. differential and integral calculus 3. linear algebra and matrices 4. probability and statistics 5. data structures 6. physics 7. differential equations 8. set theory ... And here are the "least important ... topics" to those same practitioners (where the number represents the standing of the topic in a set of 75 topics; the higher the number, the lower the standing): 72. differential equations 68. combinatorics 67. differential and integral calculus 56. linear algebra and matrices 52. computational methods and numeric problems 48. set theory 39. predicate logic 31. probability and statistics ... (The "most important" topics included 1. specific programming languages 2. data structures 3. software design and patterns 4. software architecture 5. requirements gathering and analysis 6. human computer interaction / user interfaces 7. object oriented concepts and technology 8. ethics and professionalism ...) The author specifically addresses this topic in his conclusions. "Relatively little mathematics turns out to be important for software engineers in practice, and it tends to be forgotten." And then, in a message clearly addressed to his academic colleagues, the author says "If we are to continue to teach the amount and type of mathematics [that we presently teach], we must justify it by other means than saying it is important to a software developer's work: our data show that is normally not ... At the very least, educators should look at the mathematics elements of computing [curricula] and examine how they can be made more relevant..." So there we are, with one researcher's answer to our opening question, "How important is mathematics to the software practitioner?" According to this research, at least, the answer is not only "Not very much." He goes further, and says "Not nearly as much as we academics have thought." And that raises the next, very important, question: "What should we do about that?" References: Broy 1999 - "Software Technology - Formal Methods and Scientific Foundations," Information and Software Technology, 1999 (Vol. 41, pages 947-950); M. Broy Glass 1995 - "Mathematics and the Computer Scientist," Software Creativity, Prentice-Hall, 1995; Robert L. Glass Lethbridge 2000 - "Priorities for the Education and Training of Software Engineers," Journal of Systems and Software, 2000 (Vol. 53, Number 1 (estimate, not yet published)); Timothy C. Lethbridge Young 1999 - "Computer Software Cannot be Engineered," on the author's website, April 1999, http://the2ndcr.mg1.net/cscbe.html; Norman Young ----------------------------------------------------------- Robert L. Glass Editor-in-Chief, Journal of Systems and Software Editor/Publisher, The Software Practitioner 1416 Sare Road Bloomington, IN 47401 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Professional Issues/Misc Editor) September 2000 Topic: Status of Software Engineering as a Profession After the ACM Withdrawal from SWEcc ACM's vote to withdraw from the Software Engineering Coordinating Committee (see article under "News Items") leaves the status of the development of software engineering as a professional discipline uncertain. The September FASE will attempt to provide a wide variety of opinions on this important issue. Some questions that might be addressed by contributors include: * Do you believe that software engineering is a distinct profession? Given recent events, how should the software engineering community proceed, if at all, towards the goal of having software engineering recognized as a separate discipline? * What is the outlook for the licensing of software engineers in the USA? What is your opinion concerning the licensing of software engineers? * Do you believe that it is currently possible to develop a Body of Knowledge (BoK) for software engineering? What is your opinion about the current SWEBOK efforts (http://www.swebok.org) in this regard? Of course, contributions are not restricted to answering these questions. If you would like to contribute, please contact the editor for this topic at Don.Bagert@ttu.edu. Submissions will be due by September 8. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) ACM Withdraws from SWEcc On June 30, 2000, the Council of the Association for Computing Machinery (ACM) voted to withdraw from the Software Engineering Coordinating Committee (SWEcc, but often colloquially referred to as SWECC) "as quickly as possible". This action ended seven years of joint efforts by ACM and the Computer Society of The Institute of Electrical and Electronic Engineers (IEEE-CS) to develop and establish software engineering as a professional discipline. This motion was passed by the members of the 1998-2000 ACM Council on the last day of their two-year term in office. The document "A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession" dated July 7, 2000 was released first as a printed draft and then (apparently) as an official position available at http://www.acm.org/serving/se_policy/selep_main.html. (The ACM and IEEE-CS members of SWEcc were apparently not notified of ACM Council's decision until that date.) This is from that Position Summary: "The motion passed by the ACM Council on June 30, 2000 states: "Society is becoming increasingly dependent on computers and software, which creates tremendous challenges and responsibilities for computing professionals. ACM Council believes that confronting these challenges will require creative and collaborative efforts by industry, universities, professional societies, and government. ACM Council strongly supports the idea of the ACM and the IEEE Computing Society working together on these challenges, including joint initiatives to promote the emergence of information technology professions. "However, ACM Council believes that the current efforts of the Software Engineering Coordinating Committee (SWECC) toward licensing is misguided as they assume that software engineering is a profession appropriate for licensing under the rubric of the Professional Engineers Licensing structure and requirements. Moreover, ACM Council feels that further efforts in this direction will detract from our ability to take other more practical and productive initiatives needed to meet our common goals. "Accordingly, Council directs that ACM withdraw from SWECC. Council further directs the Executive Committee to implement the decision to withdraw as quickly as possible." The aforementioned ACM Position Summary contains an executive summary, a description of the issue at hand, some background on the development of SWEcc, the May 1999 ACM Position on Licensing of Software Engineers, and several appendices consisting of a Q&A section and links to the May 15, 1999 report on the ACM Panel on Professional Licensing in Software Engineering, the May 2000 report "An Assessment of Software Engineering Body of Knowledge Efforts" by the ACM Task Force on the Software Engineering Body of Knowledge, and the draft report of ACM Task Force on Licensing of Software Engineers Working on Safety-Critical Software. (See articles later in this issue on the latter two reports.) It should be noted that the ACM approval of the chartering of SWEcc, the creation of the Licensing Panel and the May 1999 ACM Licensing Position, the creation of the two Task Forces and the vote to withdraw from SWEcc were all done by the same ACM Council (1998-2000). _____ Some excerpts from the background section: "The Joint IEEE-CS and ACM Steering Committee for the Establishment of Software Engineering as a Profession was created in 1993. [Editor's Note: This was an ad hoc committee and therefore subject to yearly review and renewal by the two societies.] This committee was superseded in late 1998 by the Software Engineering Coordinating Committee (SWECC) that was established to act as a "permanent entity to foster the evolution of software engineering as a professional computing discipline." "A key project of SWECC has been to establish a software engineering body of knowledge-or SWEBOK-project." _____ Some excerpts from the executive summary: "In recent years, the efforts of the joint Software Engineering Coordinating Committee (SWECC) have focused strongly on matters of licensing." "ACM's position is that our state of knowledge and practice in software engineering is too immature to warrant licensing. Moreover, Council felt licensing would be ineffective in providing assurances about software quality and reliability." "Because SWECC has become so closely identified with licensing of software engineers under a professional engineer model, the ACM Council decided to withdraw from SWECC." "Although ACM has withdrawn from SWECC, ACM believes the problem of reliable and dependable software, especially in critical applications, is the most important problem facing the IT profession. ACM will continue to work closely with IEEE Computer Society on projects that further the evolution of software engineering as a professional computing discipline and improve the quality of software and the capabilities of software engineers." _____ This is from the Question and Answer (Q&A) appendix: "Does ACM see a difference between licensing and certification? Yes. Certification is a statement by a recognized authority that a person is competent in an area. Licensing is permission of a jurisdiction for someone to practice his/her profession in that locality. Often licensing relies on prior certification by professional societies. But a certificate is not a license and a license does not imply competence without appropriate certifications..." Besides being available at the above URL, the ACM Position Summary will be included in the September issue of Communications of the ACM. _____ The future of SWEcc is unclear. Some IEEE-CS and ACM officials believe that the latter's withdrawal means that according to the committee's charter, it will need to be dissolved. (A copy of the SWEcc charter is at http://computer.org/tab/swecc/Charter.htm.) If so, it would then be up to the Board of Governors to decide whether or not to reconstitute or approve a replacement for SWEcc. Also unknown is the future of the Software Engineering Education Project (SWEEP), a SWEcc-sponsored project that is currently developing software engineering undergraduate curriculum models (see http://computer.org/tab/swecc/SWEE.htm). Reportedly, ACM wishes to continue working with the Computer Society on this project. The future of other projects sponsored by SWEcc are also in doubt. _____ Strongly disagreeing with ACM Council's actions is Dennis J. Frailey, SWEcc Vice-chair and the highest-ranking ACM representative on that committee, citing, among other things, lack of communication between ACM Council and its SWEcc representatives. Dr. Frailey's statement, along with two statements by ACM officials in support of the Council's actions, can be found in the article which immediately follows. _____ FASE will continue to report on this story during the coming months, including the September 2000 issue topic "Status of Software Engineering as a Profession After the ACM Withdrawal from SWEcc" (see announcement elsewhere in this issue). There will also be a thread on this topic in the FASE-TALK discussion list (see the end of this issue to learn how to subscribe to FASE-TALK). ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) Statements Regarding ACM's Withdrawal from SWEcc As of yet, there has been little official reaction concerning the July 7 announcement of ACM Council's vote on June 30, 2000 to withdraw from the Software Engineering Coordinating Committee (SWEcc). However, at the invitation of the FASE staff, three statements have been issued by key ACM officials, as shown below. _____ [Dennis J. Frailey was the vice chair of SWEcc at time of ACM's decision to withdraw from that body. He is an ACM Distinguished Lecturer, an ACM fellow, a former member of the ACM Council, a former ACM Vice President, an ACM member since 1965, an ACM volunteer for more than 30 years, and a practicing software engineer since 1962.] I strongly disapprove of the Council's decision and actions in this matter. These actions may have serious and detrimental long term ramifications to software engineering and to ACM. The work of over 400 volunteers from about 50 countries has been cast in doubt on the basis of weak and often incorrect rationale. Relationships with key external organizations that took 8 years to build have been severed, with consequential loss of good will and loss of respect for ACM on the part of these organizations. I am also disappointed at the exclusionary process by which this decision was reached. The Council and its task forces chose not to consider the views and insights of ACM's appointed SWEcc representatives and project leads - the people actually doing the work - even after we offered to provide information and to assist in the discussions and deliberations. The draft rationale for this decision contains incorrect assumptions and factual errors that we could easily have corrected and that may well have influenced the Council's decision. For example, SWEcc has never "focused ... on matters of licensing," (ask anyone who has attended one of our meetings), or "helped the State of Texas develop a licensing exam." In fact, we dissuaded the Texas Board from developing an examination and convinced them that ACM was an appropriate authority to turn to for advice in this matter. Judging from the Viewpoint letters in the May issue of CACM, where three out of four correspondents disagreed with the ACM leadership on these matters, it would seem that we are not the only ones who have a different perspective. I am hopeful that the work of the four SWEcc projects will continue under some banner and will continue to be supported by the software engineering community. Missing will be the coordination and communication functions that SWEcc provided, the united front presented by the ACM and the Computer Society working together, and the influence on these activities that ACM could have had. ____ [Ed Lazowska is Professor and Chair of the Department of Computer Science & Engineering at the University of Washington. He is Chair of the Board of Directors of the Computing Research Association and a member of the 2000-01 ACM Council. Dr. Lazowska is also both an ACM and IEEE Fellow.] The challenges related to the production of software are enormous and of critical importance -- I in no way under-estimate the seriousness of these issues. Today, though, licensing is not the answer -- it would provide false assurances to the public. I believe ACM has behaved with tremendous responsibility, and at considerable risk. I have enormous professional respect for the members of ACM's Blue Ribbon Panel, Task Force on Licensing, and Task Force on the Body of Knowledge: these individuals are the undisputed leaders of the field. [Editor's Note: The list of members of the Panel and two Task Forces, along with their final or draft reports, can be found at http://www.acm.org/serving/se_policy. Items concerning the two Task Forces immediately follow this article.] _____ [David Notkin is Professor of the Department of Computer Science & Engineering at the University of Washington. He is Chair of ACM's Special Interest Group on Software Engineering (SIGSOFT) and an ACM Fellow. Dr. Notkin was chair of the ACM Task Force on the Software Engineering Body of Knowledge, which recently issued its final report, a key factor in ACM's decision to withdraw from SWEcc.] In late June 2000, the ACM Council voted to withdraw from SWECC, the Software Engineering Coordinating Committee that has been a joint effort of the IEEE Computer Society and ACM. A draft of a statement from ACM discussing the withdrawal was distributed in early July at the CRA Snowbird conference. Although the reasons behind the action are complex and surely differ even among members of ACM Council, they are in large part based on (a) ACM's position (taken in May 1999) opposing "the licensing of software engineers at this time because ACM believes it is premature and would not be effective at addressing the problems of software quality and reliability" and (b) a perception that SWECC and one of its major projects, the SWEBOK effort on defining a guide to the software engineering body of knowledge, had become too strongly associated with the licensing of software engineers. (Note: I am chair of ACM SIGSOFT and have discussed these matters at length with members of ACM Council, but I am not a member of the Council. Furthermore, these is my personal interpretation of the situation, not an official position of any kind from ACM. I did chair a task force at the request of Barbara Simons, the then-President of the ACM, assessing existing body of knowledge efforts, including SWEBOK. A copy of the report will soon be linked from my personal web at http://www.cs.washington.edu/notkin and from the ACM policy pages found under http://acm.org.) [Editor's note: An article concerning this report immediately follows.] Discussions have already taken place between some key members of the IEEE Computer Society and the ACM about how to continue working together on SWECC's other major project, which focuses on software engineering education. ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) ACM Body of Knowledge Task Force Report Released The Association of Computing Machinery (ACM) has recently released "An Assessment of Software Engineering Body of Knowledge Efforts", a report of the ACM Council by a Task Force created especially for this purpose. The Task Force on the Software Engineering Body of Knowledge was chaired by David Notkin of the University of Washington (and SIGSOFT chair), and had two other members, Michael Gorlick of The Aerospace Corporation, and Mary Shaw of Carnegie Mellon University. This is from the report's executive summary: "Our committee was formed to study the existing software engineering body of knowledge efforts - including SWEBOK [the Software Engineering Body of Knowledge Project], with which ACM is involved through the joint IEEE CS/ACM Software Engineering Coordinating Committee (SWECC). [Editor's Note: ACM Council subsequently voted to withdraw from SWECC, in part because of this report - see article elsewhere in this issue on that topic.] Our charge was to determine the status, progress, and likely outcome of these efforts. This report documents our findings, our reasoning, and our conclusions. "Our study and analysis has led us to the conclusion that the current software engineering body of knowledge efforts, including SWEBOK, are at best unlikely to achieve a goal of critical importance to ACM: the ability to provide appropriate assurances of software quality for software systems of public interest...we believe that ACM's continued participation in the SWEBOK effort will not further - and indeed, may distract from - efforts to improve software quality, especially for systems of public interest...we are uncertain whether, at present, there exists any process to articulate a core body of knowledge in software engineering that will directly contribute to the solution of the software quality problem." The complete report is available at http://www.acm.org/serving/se_policy/bok_assessment.pdf ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) Draft Report of Task Force on Licensing of Software Engineers Working on Safety-Critical Software Released The Association of Computing Machinery (ACM) has recently released a draft report by their Task Force on Licensing of Software Engineers Working on Safety-Critical Software. Members of the Task Force include: John Knight, University of Virginia (co-chair) Nancy Leveson, Massachusetts Institute of Technology (co-chair) Lori Clarke, University of Massachusetts Michael DeWalt, Certification Services, Inc. Lynn Elliot, Guidant, Inc. Cem Kaner, Florida Institute of Technology Bev Littlewood, City University, London, UK Helen Nissenbaum, Princeton University The draft report is copyright 2000 Nancy Leveson and John Knight. _____ This is from the section titled "Background and Scope of Report": "To determine how much support ACM should be providing to licensing activities, in the summer of 1999 [then-ACM President] Barbara Simons created two blue-ribbon task forces: (1) to evaluate the Software Engineering Body of Knowledge Activities (SWEBOK) and (2) to determine ways in which ACM and the profession might improve the robustness and quality of safety-critical software and to evaluate licensing activities in this context. This report describes the initial findings and recommendations of the latter committee. A more complete report will follow later... "Barbara Simons asked the task force to look at licensing in more depth than was possible by the previous advisory panel and to focus on implications for safety... "In April 2000, the task force held a fact-finding meeting in Washington D.C. At that meeting, the task force had discussions with and got information from a group of invited experts. The presenters were: John Calvert, U.S. Nuclear Regulatory Commission; Paul Jones, U.S. Food and Drug Administration, Center for Devices and Radiological Health; Patrick Natale PE, Executive Director National Society of Professional Engineers (NSPE); Arthur Schwartz, Deputy Executive Director & General Counsel, National Society of Professional Engineers; John Adams PE, National Council of Examiners for Engineering and Surveying (NCEES); and James Moore, Mitre Corp, member of SWECC and SWEBOK. "Although the investigations are not yet complete and the final task-force report will not be finished until later in 2000, Barbara Simons asked the task force to provide an update of its activities and findings for the May 2000 meeting of the ACM Council. We include in this report only the findings, conclusions, and recommendations related to PE licensing and the software-body-of-knowledge activities." The draft report also contains sections on Licensing and Software Body of Knowledge and Curriculum Activities, and then ends with General Conclusions and Recommendations. _____ The Task Force findings related to licensing, according to the draft report, are: "Presently, licensing as PEs would be impractical for software engineering." "Licensing software engineers as PEs would have no or little effect on the safety of the software being produced." The conclusion the Task Force made related to their findings on licensing was: "The licensing of software engineers as PEs at best would be ignored and at worst would be damaging to our field. It would have no or negligible effect on safety." _____ The Task Force "preliminary set of findings" related to software body of knowledge and curriculum activities were: "1. There is no generally agreed body of knowledge (BoK) for software engineering at this time. "2. The rate of change of the field suggests that there is little chance of developing a documented BoK that would not be obsolete for much of its existence. "3. Safety-critical software and systems have special needs and knowledge that are excluded from the IEEE SWEBOK effort (for example, real-time systems are excluded). Only universally required and applicable knowledge is being included. Thus it will have little relevance for safety-critical systems and may dangerously exclude the most important knowledge related to competence to build these systems or imply that having the knowledge included will make a person qualified to build safety-critical systems. "4. Because little scientific evaluation of software engineering techniques has been done, it will be difficult to get consensus on what is effective and should be included or excluded and the differentiation between knowledge and fad. "5. Few textbooks or programs exist that provide adequate instruction on building safety-critical, real-time software. Standard software engineering textbooks and classes do not provide adequate instruction in these special aspects of software engineering and thus do not prepare students to work on such systems. This is particularly true for application software." The Task Force's General Conclusions and Recommendations had two sections, "General Findings and Conclusions" and "Recommendations". The General Findings and Conclusions: "With respect to safety-critical software: "1. An effective approach to ensuring safety in software-intensive systems will require a systems approach and will not involve simply dealing with the software in isolation. "2. Each industry will need to determine an appropriate mix of approaches that work together to solve their particular problems and fit within the cultural context of that industry. There are no simple and universal fixes that will solve the problem of ensuring public safety. Effective approaches will involve establishing accountability (including corporate and not simply individual accountability), competency within application areas and job responsibilities, liability, regulation where appropriate, standards, and industry-specific requirements." The Recommendations: "With respect to safety-critical software: "1. The ACM should withdraw from efforts to license software engineers as professional engineers. "2. The ACM should take a stand against government efforts to require the licensing of software engineers as impractical, potentially ineffective with respect to safety-critical projects, and potentially detrimental with respect to economic and other societal and technological factors." [Editor's Note: In fact, ACM had already done this, in May 1999.] "3. Textbooks and other educational programs should be developed that focus on software engineering in real-time, safety-critical systems. "4. The ACM should not support the SWEBOK activities but should consider supporting other efforts to validate and codify basic knowledge in various aspects of software engineering." [Editor's Note: As stated elsewhere in this issue, ACM on June 30, 2000 withdrew from the Software Engineering Coordinating Committee (SWEcc), which includes SWEBOK as one of its activities.] _____ The complete draft report is available at http://www.acm.org/serving/se_policy/safety_critical.pdf ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) Licensing Workshop at CRA Department Chair Conference The workshop "Software Engineering Licensing and Certification" was held at the Department Chair Conference sponsored by the Computing Research Association (CRA) on Tuesday, 11 July 2000. This conference is held once every two years at Snowbird, Utah, USA for department chairs of computer science and engineering programs in the United States and Canada. David Notkin, Professor of the Department of Computer Science & Engineering at the University of Washington, ran the workshop. He is Chair of ACM's Special Interest Group on Software Engineering (SIGSOFT), and was also chair of the ACM Task Force on the Software Engineering Body of Knowledge, which recently issued its final report - a key factor in ACM's decision to withdraw from the Software Engineering Coordinating Committee (SWEcc). (An article about that report appears elsewhere in this issue.) The slides used in Dr. Notkin's presentation are available at http://www.cs.washington.edu/homes/notkin/se_licensing_snowbird_files/ frame.htm Dr. Notkin (literally) used "three hats" in his presentation: "FACT" (generally-accepted facts related to the licensing of software engineers), "I SAY" (his personal opinions concerning licensing, and "OTHERS SAY" (opinions of some others concerning licensing). He noted that CRA is primarily a North American organization; the presentation was USA-centric in part due to that fact. Among the FACTs cited by Dr. Notkin: * Software is of the public interest. * There are various approaches to validating quality (e.g. product, organization, individuals; the latter is concerned with licensing/certification). * There are many forms of credentialing individuals (e.g. licensing, professional organization certification, private/company-based certification). * This presentation focused on professional registration (e.g. lawyers, doctors, professional engineers) and in particular the licensing of software engineers. * Professional registration is managed in the publish interest, and held to a high standard. * Private certifications (e.g. Microsoft Certified System Engineer, Novell Certified Network Engineer) are usually of little interest to the general public. * There is significant interest in licensing SEs in the USA. * There are varying type of laws and degrees of enforcement in the different states of Professional Engineers (PEs). * A PE is not licensed as discipline-specific, but is excepted to work only in his or her engineering area(s) of competence. * The percentages of engineers licensed as PEs vary widely among engineering disciplines. * Mandatory PE licensing is required for those providing services directly to the public and for those involved in the design of public facilities. Exceptions: federal employees, those in a company and not providing direct service to the public. * The Fundamentals of Engineering (FE) Exam is given in the United States to graduating engineers. It has a general component in the morning (including lab and engineering sciences) and a discipline- specific component in the afternoon. After four years of practice, a Principles and Practice of Engineering Exam (P&P), which is also discipline-specific) is given. Passage of both exams can lead to licensing as a PE. (There are exam waiver clauses - in all engineering disciplines, not just software engineering - in states such as Texas.) * The basis for the FE afternoon and P&P exams is a core Body of Knowledge (BoK) that reflects actual achievable good practice, and which can provide a high quality product for the public. However, competent use of the BoK by a Professional Engineer does not absolutely guarantee reliability. Among the "OTHERS SAY" cited by Dr. Notkin: * Arguments for licensing: It would provide, in applicable situations, assurances to the public, be a driver for the improvement of software, give software engineering status as an engineering profession, and help SE become more respectable. Among the "I SAY" (i.e. what Dr. Notkin says) cited: * Arguments against licensing: It would not be effective at improving software quality, would provide false assurances to the public about software quality, is premature in the absence of an agreed BoK that commands the respect of the community. Dr. Notkin also mentioned William Wulf's comments about software engineering ethics made earlier in the conference (see the article which immediately follows this one). _____ This workshop was held only four days after the announcement that ACM was withdrawing from the Software Engineering Coordinating Committee, which was organized jointly with the IEEE Computer Society (see separate articles on the subject). With this in mind, it was not surprising that the ACM and IEEE-CS officials in the audience made comments that in general supported the positions of their respective organizations. Among the comments made by audience members: * Regardless of what percentage of PEs were licensed in a particular discipline, it is likely to affect that discipline's curriculum nonetheless. * SWEBOK addresses a single body of knowledge for software engineering, and not does address the wide variance of knowledge needed across application domains. * Many companies that have developed highly-reliable safety-critical software feel that they have a well-defined body of knowledge for software engineering. * The licensing of software engineers as PEs would mean that students would have to study material for the FE that is not applicable to software engineering. * There was some question about what about system engineers signing off on the system, including software, were signing off on - the integration of the components, or all of the component parts? If it is the latter, having a PE approve of the software is important. ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) Wulf Expresses Concern Regarding Software Engineering Ethics William A. Wulf, President of the National Academy of Engineering and AT&T Professor at the University of Virginia, gave the dinner talk at the opening night of Computer Research Association Conference for Department Chairs of USA and Canadian Computer Science and Engineering programs on July 9 at Snowbird, Utah, USA. The talk was titled "Some Challenges for Computer Science as it Enters the 21st Century". Much of the talk consisted of "Challenges" that Dr. Wulf saw for the next century. He introduced the slide entitled "Challenge: Ethics when you know what you're doing and can't!" by jokingly remarking that he was told shortly before the talk that there was a Software Engineering Code of Ethics [Editor's Note: The Code was developed by a joint ACM/IEEE-CS Committee; see http://computer.org/tab/swecc/SWEE.htm], and that concerned him a bit. One remark from the slide was "What's ethical if you know the system will have properties that you can't predict?" He went on to state that in other engineering disciplines, the solution is to overdesign, but that isn't possible for software engineering, because that would add complexity to the software that would cause even more problems. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE FASE is published on the 15th of each month by the FASE staff. 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 and all other categories to Don Bagert . If the article for a FASE topic where there is a guest editor, the submission should instead be to that person. Items must be submitted by the 8th of the month in order to be considered for inclusion in that month's issue. Also, please see the submission guidelines immediately below. FASE submission format guidelines: All submissions must be in ASCII format, and contain no more than 70 characters per line (71 including the new line character). This 70-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. All characters (outside of the newline) should in the ASCII code range from 32 to 126 (i.e. "printable" in DOS text mode). _____ Subscribe/Unsubscribe Information as of February 15, 2000 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, in reverse order, or through ftp at . _____ 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 Email: carter@wwa.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