Forum for Advancing Software engineering Education (FASE) Volume 12 Number 05 (Issue 148) - May 15, 2002 Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents This Month's Topic: Computer Science and Software Engineering in Academia: Cooperation or Conflict? Introduction by Tom Hilburn and Don Bagert Florida Tech Software Engineering Program by Cem Kaner Conflict in Canada over Software Engineering by Jonathan Mohr Need for Integration: CS & SE in Academia by Ken Surendran SE and CS: Conflict, Harmony, War, and Diversity by J. Barrie Thompson Articles Introductory Programming Courses for Software Engineering Students: A Position Statement by Rick Duley Obituaries Norm Gibbs - A Leader in Software Engineering Education Calls for Participation Working Conference on Reverse Engineering - NOTE DEADLINE! Position Openings Pennsylvania State University at Erie Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This Month's Topic: Computer Science and Software Engineering in Academia: Cooperation or Conflict? Topic Editors: Tom Hilburn and Don Bagert Throughout the international community, the number of software engineering degree programs are increasing, with more rapid growths expected in the near future. Most of those new software engineering programs will grow out of existing computer science departments, meaning that CS and SE stakeholders are potentially competing for resources. On the other hand, some departments have the various interests working together, in some cases even changing its name to "The Department of Computer Science and Software Engineering". The long-term future of many departments may depend on whether there is cooperation or conflict between the computer science and the software engineering faculty. The following articles address some of the issues concerned with these competing interests of CS and SE stakeholders. ###################################################################### Florida Tech Software Engineering Program Professor Cem Kaner, J.D., Ph.D. Department of Computer Sciences Florida Institute of Technology kaner@kaner.com This month's theme in FASE is "Computer Science and Software Engineering in Academia: Cooperation or Conflict?" This is a status report from a school in which there is more cooperation than conflict between faculty who are primarily CS and those (like me) who are primarily SE. Florida Institute of Technology's Computer Sciences Department offers undergraduate degrees in Computer Sciences, including a traditional CS track, a more applied Software Development track, and an Information Systems track. At the Master's level, we offer a CS degree, two Software Engineering degrees (one focused on software development, the other on software management) and a career retraining degree that we call Information Systems. We are a relatively small department (12 full-time faculty plus 2 research faculty who also teach occasional courses within the department). Three or four of us are more SE-focused than CS, as are the two research faculty. The majority of current grant-based research funding has been awarded to the software engineering faculty. We have openings for new faculty (at least one more), and we would welcome a strong candidate either on the CS side or the SE side. For a few years, we were two departments (CS and SE). Software Engineering offered a Master's program with plans to develop an undergraduate degree. But we had good relations across the two groups, and a competent and popular chair in CS who was willing to accept the added burden of the SE program, so the Departments merged. I chair the CS Department's curriculum committee. Recently, we completed our overhaul of the undergraduate and graduate software engineering programs. * We revised our Software Development track to create a Software Engineering degree track. We expect to seek ABET accreditation for this track as an undergraduate software engineering degree. The program will be published in our 2003-2004 Calendar. We will start teaching students within that program in 2002-2003. * We also merged the two Master's SE programs, eliminating the management track, increasing the required CS background for entry into the program, and requiring a more technical focus of all Master's students. The comments that I'll make in this report are my own observations. I don't speak for Florida Tech, for the CS Department or even for the Curriculum Committee. In some cases, other members of the Department might flatly disagree with my opinions or interpretations of events. Because this is a personal observation, here is some background on me. My background is primarily in industry. I started working in Silicon Valley in 1983 and have helped develop consumer software, PBX control software, printer firmware, and COTS financial applications. I have done (and managed) every technical aspect of software development, including programming and design, human factors analysis and user-centered design, testing, and user documentation. Additionally, I was an associate in an organization development consulting firm for a while, have sold software at retail, and became an attorney, whose focus is the law of software quality, in 1994. From 1994 to 2000, I ran a successful solo practice, offering software development management consulting and software law consulting / representation. In 2000, I joined Florida Tech's Software Engineering Department (which soon merged into CS) as Professor of Software Engineering. My first doctorate was in Experimental Psychology, in a subfield called Psychophysics: measurement theory applied to the question of how we measure subjective events (sensations and perceptions). The primary applied path from psychophysics is human factors. I've published three books: Testing Computer Software, Lessons Learned in Software Testing, and Bad Software: What To Do When Software Fails. OUTLINE (A) COMMENTS ON THE MASTER'S DEGREE (B) OBJECTIVES AND CONSTRAINTS OF THE UNDERGRADUATE PROGRAM (C) THE UNDERGRADUATE COURSE LIST (D) DESCRIPTIONS OF SOME OF THE COURSES (E) WHAT WE MIGHT ADD (F) NOT ON THE LIST (A) COMMENTS ON THE MASTER'S DEGREE The graduate degree in Software Engineering, especially the management track, was the subject of several critical comments from faculty -- especially CS-focused faculty. There was a perception that the program allowed students to graduate with insufficient technical knowledge and skills. Some of the comments made could have been interpreted as offensive or demeaning by SE-focused faculty. Ultimately, instead, we tried to understand what was behind some of the comments and revised the program. Not all of the students in the program were good programmers. Some of the students came into the program because they enjoyed computing, but not programming. Of those students, my impression is that they might hire well into positions focused on software process improvement or quality control, and they might gain promotions within those groups, but their career flexibility is probably limited. I base that impression on my experience as a consultant. I helped several companies form software testing, documentation or development groups and have a good sense of the skill sets they recruited for and the career paths of many of their (successful and unsuccessful) managers. Another impression of mine is that students who came into the program without practical experience in the field found the courses in metrics, requirements, and process very theoretical. The students may have gotten A's in the courses, but they didn't have the experience-based wisdom to appreciate what they were learning. Some of these students faced rough challenges when they got jobs in real companies, which did things in really different ways from what the students learned in class. I think that the criticisms from the CS faculty boiled down to two important concerns: (a) our students should graduate with strong technical skills that will enable them to find work quickly, and to move freely across several different types of positions within a software development group. (b) our students should take practice-focused classes, but the material they study should be appropriate to the maturity and experience of the student. Ultimately, we merged the technical and management tracks. In the new program, Masters SE students are required to take these graduate level courses: - Software Engineering 1 (a project course focusing on individual projects), - Software Engineering 2 (a project course focusing on team projects), - Software Testing 1, and - Software Metrics and Modeling. They must take three "restricted electives" courses - one "programming" course (a course that develops programming skills, in which programming assignments make up a substantial portion of the evaluation) - one "foundations" course (such as formal languages, operating systems, or databases), and - one "software engineering" course (such as software engineering process, requirements analysis, software maintenance, or one of the special topics courses frequently offered by the SE faculty). And they take one or three additional elective courses (one with a thesis, three with comprehensive exams). (B) OBJECTIVES AND CONSTRAINTS OF THE UNDERGRADUATE PROGRAM 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 a good definition. Note that it includes most of the _practicing_ software development community. A program in software engineering would teach students how to apply engineering principles and practices to the analysis, specification, design, development, certification, maintenance and testing of software systems. Those principles and practices include an emphasis on problem solving, cost/benefit evaluation, professional responsibility, and getting a product to actually work, at a level of reliability, usability (etc.) that is suitable for the intended contexts under which it will be used. We accepted several constraints on the program: First, It would be a 4-year degree, not 5. Second, it would be designed to be accreditable as a computer science degree track. That is, our students would meet the minimum requirements for a degree in CS, and have several additional requirements specified on top of the CS requirements. We agreed on this for several reasons, not least of which was risk management. Software engineering programs are new. There is not an accepted curriculum. The primary project intended to define the body of knowledge of software engineering (SWEBOK) has been very controversial and is not universally accepted as a trustworthy guide. We agreed unanimously (SE and CS faculty alike) that we would best serve our students by designing a curriculum that would fully qualify them for admission into a graduate program in CS, while also training them for practice in the field. We were very aware of comments that a CS program is too theoretical for software engineers, that many of the traditional CS courses are inapplicable, or at least are not applied on the job. On the other hand, several of us have practical and theoretical experience in software testing. Testing accounts for up to 50% of the software development expense of many projects. It is, for better or worse, a fundamental task within software engineering. Testing has been a practice-focused field. Little computer science theory has seeped into testing, at least as it is practiced in industry. Unfortunately, the complexity of software to be tested has grown enormously over the past two decades, but the state of the practice of software testing has not kept up. Most of the methods in use today were commonly practiced in the early 1980's or are minor partial automations of methods commonly practiced in the early 1980's. The belief of several of us (certainly, my belief) is that the field has been slow to develop or adopt new practices because too few software testers have strong computer science backgrounds. They don't have the backgrounds they need to develop or appreciate new approaches. Opinion leaders in this field often have strong backgrounds in process management, project management, requirements analysis, human factors, and metrics. But remarkably few of them can explain what a basis path is (or graph it), can create a state model of a system, can appreciate the difference between calculation results being slightly wrong due to algorithmic errors vs rounding errors, or can design and implement tools appropriate to their needs. We expect several of our top graduates to (continue to) seek and find positions in testing groups at interesting companies. We expect them to grow into technical leadership roles in those groups. We expect several other of our top graduates to seek and find positions involving system security. In our experience, deep knowledge of a system, combined with skill in testing, provide excellent background for security-related work. Given this strength and interest in our department, we have a strong preference for building a program that will graduate people who can extend the state of the practice in software testing. In our view, after careful evaluation, we believe that every CS course in the curriculum we offer adds value toward that objective. In designing the curriculum, we chose not to require students to take traditional engineering courses (mechanical engineering, differential equations, etc.) We are not convinced that we are, or should be, preparing students to be traditional PE's. Some students need deep knowledge of some other areas of engineering in order to build appropriate products, but the same is true for students who will eventually design medical, financial, or educational systems. We saw no reason to prefer one subject matter domain (e.g. electrical engineering) over another (e.g. financial)--software engineers will work on both types of systems. In designing the curriculum, we were also conscious of the extent to which software engineers have to design for people, and have to present their plans to people. We added two humanities requirements (Logic and Scientific/Technical Communication) beyond our school's standard set of humanities requirements. We also require students to study introductory psychology and human factors analysis. I'll comment on a few other courses after laying out the curriculum that we agreed on. (C) THE UNDERGRADUATE COURSE LIST Freshman Year Fall Credits COM 1101 Composition and Rhetoric 3 CSE 1001 Fundamentals of Software Development 1 4 CSE 1101 Computing Disciplines and Careers 1 MTH 1001 Calculus 1 4 MTH 2051 Discrete Mathematics 3 Spring COM 1102 Writing about Literature 3 CSE 1002 Fundamentals of Software Development 2 4 MTH 1002 Calculus 2 4 HUM 2510 Logic 3 PSY 1411 Introduction to Psychology 3 Sophomore Year Fall COM 2223 Scientific and Technical Communication 3 CSE 2010 Algorithms and Data Structures 4 CSE 3411 Software Testing 1 3 PHY 1001 Physics 1 4 PHY 2091 Physics Lab 1 1 Spring Credits CSE 2050 Programming in a Second Language 3 CSE 2410 Introduction to Software Engineering 3 MTH 2401 Probability and Statistics 3 PHY 2002 Physics 2 4 PHY 2092 Physics Lab 2 1 Restricted Elective (Science) 3 Junior Year Fall Credits CSE 3101 Machine and Assembly Language 3 CSE 4415 Software Testing 2 3 CSE 4621 Software Metrics and Modeling 3 COM 2012 Research Sources and Systems 1 HUM 2051 Civilization 1 3 Restricted Elective (Science) 3 Spring Credits AHF 3101 Introduction to Human Factors 3 CSE 3030 Legal, Ethical and Social Issues in Computing 3 CSE 3421 Software Design Methods 3 CSE 4610 Requirements Engineering 3 HUM 2052 Civilization 2 3 Free Elective 3 Senior Year Fall Credits CSE 4001 Operating Systems Concepts 3 CSE 4201 Software Engineering Projects 1 3 Computer Science Elective 3 Free Elective 3 Social Science Elective 3 Spring Credits CSE 4083 Formal Languages and Automata Theory 3 CSE 4202 Software Engineering Projects 2 3 Computer Science Elective 3 Free Elective 3 Humanities or Social Science Elective 3 TOTAL CREDITS REQUIRED 128 (D) DESCRIPTIONS OF SOME OF THE COURSES A few of these courses might be non-standard in their design. In particular: (a) SOFTWARE TESTING 1 focuses on black box software testing. Here, we teach a go-for-the-virtual-throat style of testing, teach testers how to investigate problems and write problem reports, and the basics of black box test automation, test planning and test group management. There are several strikingly different styles of black box testing. The styles differ strongly in the types of problems they can readily expose and the types that will be invisible to the method or hard to find. Companies differ widely in the selection of styles their test groups adopt--many companies rely heavily on one or two styles. We teach a context-driven approach: several styles, and several factors that might influence your choice of a given style at a given time within a given project. Throughout the course, students test a significant commercial product undergoing current development, try out different styles, and file defect reports with the company developing the product. Starting in the first or second lecture of the class, students learn that the fundamental problem of testing is that there is infinitely more work that "should" be done than we have time or budget to do. The time you spend on one task is time taken away from another. All tests, all artifacts, all activities are subject to cost-benefit analysis. (b) SOFTWARE TESTING 2. Students have taken Testing 1. They know a lot about testing. Here, we give them the source code to the product. If this was your code, or the code of a colleague, what tests should you run? Students learn to work with JUNIT and other Java test tools and frameworks. They learn the value of test-first programming, design for testability, and techniques for embedding oracles in the code, along with the usual coverage analysis and logic analysis that is so much easier to do and understand when you can work with the source code. (c) SOFTWARE METRICS AND MODELING. Measurement is important, but many software measurement programs fail. Some might fail because of a lack of professionalism, or laziness, or lack of interest in quality or lack of sophistication of the staff. But many failures stem instead from (often well-founded) mistrust of the measurements and the people who take them, lack of respect for the models that relate the measurements taken to the attributes they supposedly measure, and examples of manipulation or misuses of the data collected. These are serious problems. The course takes them seriously. This course looks at a few of the common software metrics -- especially of coverage and complexity. It uses these to ask what makes a metric valid or invalid, useful or dangerous. We consider the problem of models (given an attribute and a procedure to allegedly measure the attribute, what model ties changes in the attribute to changes in the measurement? If there is no model, what are we measuring?) From here, we study some economic models of measurement (Robert Austin's work) as a framework for thinking about measurement dysfunction -- measurement always has an effect on the organization, but sometimes the effect is so negative that you would have been better off with no measurement program than with this one. This is dysfunction. Despite the risk of dysfunction, measurements are needed. We consider approaches that can (if used well) combine imperfect measures into a better whole, such as the Goal / Question / Metric approach, COCOMO 2000, and balanced scorecards. We also look at some issues in design of experiments and statistical modeling, to help students evaluate studies given to them that make various claims about the efficacy of a given metric or combination. (d) SOFTWARE ENGINEERING PROJECTS 1 AND 2 focus the student initially on individual-contributor-level work. The student tracks her work, errors, estimates, etc. In Projects 2, students come together into teams. Practices that seemed unnecessary in a group of 1 (such as various types of process documentation) become more obviously necessary in groups of 5. (E) WHAT WE MIGHT ADD It's interesting to see what almost made it into the curriculum but just wouldn't fit. These courses, or the content of them, are likely to come up again and again. (a) SOFTWARE ENGINEERING ECONOMICS. Students learn much of this in other classes. They learn about cost/benefit tradeoffs in several courses, including software engineering and software testing 1 and computer law and ethics. They learn COCOMO in the metrics class. Still, we think it would be valuable for the software engineer to be able to create a project budget, to do some financial recordkeeping against the budget, to spot changed or unexpected circumstances and costs and to justify revisions based on changed circumstances. This course would teach a combination of economics and project accounting principles to developers. (b) DATABASES. This is a traditional CS course, but databases are present in so many systems that the competent developer should know a lot about them, and how to work with them. (c) ADVANCED MODELING. There are several different types of models you can make of a system. This course would give students an overview of several different types, and focus small groups of students on projects in which they develop a few specific models. (d) SOFTWARE MAINTENANCE AND CONFIGURATION MANAGEMENT. We have a course that covers this material. It's still under development, being substantially improved each year. We don't have room for it as a required course in the curriculum (there are too many required courses already), but maybe it will come in as the program settles out. (F) NOT ON THE LIST We offer an optional course in software development processes, and we cover process-related issues in the software engineering intro and projects courses. Should we create a required course for this material? An important concern about process courses is that many undergraduate student lack the project experience to appreciate the issues and risks being considered in the course, and controlled by the process under study. As a result, as a requirement for ALL students, the course might do more harm than good, or simply be a course that drives students to intensive memory work. (G) COMMENTS WELCOME This is a new program. We've been teaching most of the components for several years, but the combination is new. I'd welcome your comments, praise and criticism. ###################################################################### Conflict in Canada over Software Engineering Jonathan Mohr Professor of Computing Science Augustana University College Camrose, Alberta, Canada mohrj@augustana.ab.ca Any discussion of Software Engineering programs in Canada must take into account the continuing conflict between the Canadian Council of Professional Engineers (CCPE) and the universities regarding any Software Engineering program offered outside a Faculty of Engineering. In most or all of the provinces in Canada, as in at least some states in the U.S. [http://www.tbpe.state.tx.us/Downloads/eb17.htm], the term "Professional Engineer" is protected by legislation and may only be used by licensed engineers. In my province of Alberta, the Engineering, Geological and Geophysical Professions Act further specifies that no one may "use the word 'engineer' in combination with any other name, title, description, letter, symbol or abbreviation that represents expressly or by implication that he [sic] is a professional engineer, licensee or permit holder" unless he or she is licensed by The Association of Professional Engineers, Geologists and Geophysicists of Alberta (APEGGA) [http://www.apegga.com/aboutapegga/theact.html]. There are several cases which illustrate the aggressive enforcement of the protection of the term "engineer" by both the national and provincial engineering associations. In the most famous case, Memorial University of Newfoundland was sued in federal court for infringement of a trademark allegedly owned by CCPE and/or the Association of Professional Engineers and Geoscientists of Newfoundland (APEGN) after the university Senate approved an honours science degree with a specialty in "software engineering" in 1996 [http://www.mun.ca/univrel/communicator/Apr.99/name.html]. In 1999, the CCPE discontinued its lawsuit as a result of an agreement with the Association of Universities and Colleges of Canada (AUCC) and Memorial which stipulated that "an independent panel will be established to make non-binding recommendations on the appropriate use of the term 'software engineering' by Canadian universities [http://www.aucc.ca/en/comm/sep2499.htm]. The panel "released its report in July 2000, recommending that software engineering programs be accredited by a proposed new Software Engineering Accreditation Board. The accreditation criteria and procedures of the new board would be developed jointly by the Canadian Engineering Accreditation Board -- the CCPE arm that accredits undergraduate engineering programs -- and the Computer Science Accreditation Council, an agency of the Canadian Information Processing Society that accredits undergraduate computer science programs" [http: //www.aucc.ca/en/university_affairs/feature/2001/october/pg42.pdf]. However, after the two accrediting bodies had jointly drafted an accreditation plan for the SEAB, the CEAB "recommended a number of significant changes to the structure and curriculum requirements of [SEAB] without consulting the [CSAC]. The CCPE subsequently passed a motion supporting the [panel] recommendations based on the amendments from its accrediting arm" (ibid.) The AUCC concluded that it could not endorse the panel's approach due to "the current state of relations between the engineering and computer science communities" (ibid.) The CEAB has subsequently accredited three software engineering programs, all offered through the universities' engineering faculties. When the University of Saskatchewan approved a software engineering specialization as part of its B.Sc. Honors program in Computer Science, its Dean of Engineering published a warning entitled "Facile use of the term 'engineering' is unconscionable" in which he states that "the title of the Software Engineering specialization erroneously describes a science discipline that's recognized only by Computer Science" [http://www.usask.ca/communications/ocn/Feb27/opinion.html]. A second case of the CCPE enforcing its monopoly on the term "engineering" saw them take on Microsoft over its licencing program "Microsoft Certified Systems Engineers". Microsoft Canada ended up agreeing to cease using the word "engineer" in connection with its MCSE certification. Instead, Microsoft resorted to the expedient used by other corporations (KFC comes to mind) of simply never spelling out the abbreviation: you may be a "Microsoft Certified Systems Engineer" in the U.S., but in Canada you are just an "MCSE" [http://www.apegga.com/whatsnew/peggs/Web11-01/persuasion.htm]. A third case was recently reported by ComputerWorld Canada (March 8, 2002, pp. 14, 16): "When Kent MacDonald placed an ad in the local newspaper for a 'systems engineer' to join Ram Computer Group Inc's Calgary office a few years ago," he received a letter from APEGGA asking him to "'cease and desist' using the title 'engineer' in its ad." The article went on to quote Dave Todd, APEGGA's director of compliance, regarding the need to protect the term "engineer" in order to avoid confusion. Todd went on to observe that "A lot of electrical engineers, for example, if they're working in the [IT] industry, could call themselves 'software engineers' legitimately. We have a code of ethics that says we're only supposed to practice in areas where we're competent. If the electrical engineer has become competent in that area, they could use the title. They're not misrepresenting themselves as long as they're registered." [http://www.itworldcanada.com/portals/- portalDisplay.cfm?oid=990B2D23-0527-450C-AC3D7BDC4553F281] To me, this last point is the truly disturbing part of this conflict in Canada -- a civil engineer who was trained to build sewage systems could conclude, based on the course in Fortran which was required by the Faculty of Engineering in the 1970's, that he or she is competent as a software engineer, and would be fully licenced to use the term, while a graduate of a Computer Science program with a specialization in Software Engineering could face civil or criminal prosecution for use of the same designation. I fail to see how this protects society. ###################################################################### Need for Integration: CS & SE in Academia Ken Surendran Southeast Missouri State University ksurendran@semo.edu) The evolution from Computer Science (CS) to Software Engineering (SE) is a natural one. SE plays a major role in enhancing the value of CS to society, since CS is its foundation. While there is a large common area between CS and SE, the two move in opposite directions of the IT spectrum for growth. CS aims to build a broader and deeper foundation for enhancing the software aspect of the infrastructure which in turn enables SE to explore new application domains. (Computer and Communications Engineering enhance the other aspects of the infrastructure.) The demand for SE is growing as more and more new application possibilities are explored. Unlike the other engineering disciplines, in SE, there are no theoretical limits (no limiting physical laws) for this exploration. The growth is mainly limited by the infrastructural and resource constraints. Lack of appropriate infrastructure requires more resources in developing quality products. For instance, the current challenges in Bio-informatics and the need for highly secured distributed application systems can be better addressed by developing new software infrastructure, as reusing the inappropriate ones consuming more resources. So, there is constant feedback from the application domain through SE to CS for enhancing the foundation. All these indicate the need for a closer cooperation between CS and SE. Both CS and SE can benefit through coexistence. Institutions offering traditional engineering programs (institute of technologies) may have a congenial educational philosophy for the integration of CS and SE. Such integration, however, is still somewhat limited since it misses out the other player (Computer and Communications Engineering). Some institutions have taken a pro-active step in forming a School of IT to integrate all these related disciplines. Also, the recent ABET accreditation initiative seems to recognize this integrative trend. ###################################################################### SE and CS: Conflict, Harmony, War, and Diversity J. Barrie Thompson Professor in Applied Software Engineering Vice Chair IFIP WG3.4 School of Computing Engineering and Technology University of Sunderland, United Kingdom. barrie.thompson@sunderland.ac.uk I welcome this opportunity to express some views on the relationship between Software Engineering (SE) and Computer Science (CS). The SE community needs to consider the real problems that currently exist if there is to be significant advances within our discipline in the future. The following short sections each attempt to provide a contextual heading, a question, and some information that may help answer the question or at least understand it better. 1 Vested Interests and Conflicts Q: Why are there so few undergraduate SE programmes in certain parts of the world? As many readers of FASE know, during the last two years, with the help of my colleague Prof. Helen Edwards I have been promoting the consideration and evaluation of a document produced under the auspices of the International Federation for Information Processing (IFIP). This "Harmonisation of Professional Standards" document essentially defines a framework for professionalism that could be applied world-wide. The activities to promote it have included: * A paper detailing it along with a copy of the document itself was presented at the 2000 Computer Software and Applications Conference (compsac2000) which was held in Taipei in October 2000. * It was also used as the focus for a panel session at the same conference. * 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 appeared 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 subsequently appeared in ACM SIGSOFT Software Engineering Notes. In various discussions both in formal sessions and afterwards in informal conversations a clear message is that there are major problems, especially in the US, of supporting the SE discipline with appropriately orientated academic programmes of study. In particular, it appears that within the US much of the academic sector is orientated towards CS programmes to the detriment of SE. This leads to a major problem within the university sector of "turf wars" concerned with faculty (staff) numbers when it comes to initialising SE programmes of study. It appears that in many cases to run a SE programme would mean a possible decrease in CS staff for SE staffing to increase and that this is a highly emotive issue. Flexibility in staffing allocations, as occurs in other countries, simply does not appear to enter the equation. Thus the vested interests of one group (CS) is obviously stifling the growth of SE programmes especially at undergraduate level. 2. Diversity and Harmony Q: How can innovation and experimentation flourish? In the UK, and as far as I am aware in most of Europe and also in Australia, the situation is very different to the US, with flexibility in programme provision being a more normal situation. A contributing factor is no doubt recognition of the overall discipline as Computing or Informatics with both SE and CS being recognised as only two sub disciplines within a much wider range. In particular, with regard to the UK, it appears that actions by the government are actually supportive of diverse provision whilst still ensuring the standards of awards in higher education. The government created body responsible for standards is the Quality Assurance Agency for Higher Education (known as QAA - for details see: www.qaa.ac.uk). This body has oversees the definition of frameworks for higher education qualifications (which should ensure comparability of awards from different institutions and in different subjects) and subject benchmarks statements (which provide a means for the relevant academic communities to describe the nature and characteristics of programmes in their subject areas). The benchmark statements for Computing were developed by a group of 18 senior academics and involved consultative meetings with the academic community. The title Computing was chosen as being the most representative for the discipline as this was the overwhelming view of the academic community that was expressed at a consultative workshop. The Computing Benchmark document recognises the diversity of computing as practised within the UK and that in 1999, UK universities and colleges offered over 2400 undergraduate programmes in Computing, with 15 different titles for single-subject degree programmes alone. Thus benchmarking standards have been produced that will accommodate a wide variety of programmes: including modular and non-modular courses, both vocational and academic programmes, and programmes focusing on different aspects of computing. An annex to the benchmarking document provides an list of 33 knowledge areas which are seen as indicative of the scope of the broad area of Computing. These topics range from Architecture through Databases, Information Retrieval, Professionalism, and Software Engineering to Web-based Computing. Each of these knowledge areas is also broken down into a number of topics. 3. Communities at War Q: Can a computer scientist impartially evaluate a SE project and vice versa? Much of what we do (or to be more exact what we are funded to do) depends on the results of peer reviews and evaluations. This is a system that should produce fair and equitable results so long as those involved act ethically and impartially. In the previous section I presented a very positive picture of the situation in the UK which I believe is reasonably accurate with regard to the provision of undergraduate and postgraduate programmes. However, when it comes to the funding of research I feel that in the UK many of the sub computing disciplines, including SE, lose out. A major problem is that at the heart of the system lies the five yearly Research Assessment Exercise which is run by the higher education funding councils. Details of the RAE can be found on the web site for the higher Education Funding Council for England (hefce): www.hefce.ac.uk/research. Basically academic institutions can submit details of their research and its outputs in up to 69 subject areas (known as Units of Assessment UoA). Each submission is given a quality rating judged against standards of national and international excellence. This is done on a seven point scale from 1 (the lowest) though 2, 3b, 3a, 4, 5 and 5* (five star - the highest). So far so good, but the UoA for our discipline is UoA25 and that is named Computer Science! Of course, I believe that assessment panels are as unbiased as they can be but I would contend that there is much in a name and if you have a UoA named Computer Science and you have humans with all their frailties doing the assessment that name will produce a unwitting bias. That some Institutions do believe that there is a possible bias can be seen from the fact that they submit their computing staff in UoA61 Library and Information Management rather than UoA25 Computer Science! It is a less than perfect situation that research is judged under a banner of Computer Science, while QAA has "blessed" the community chosen name of Computing, many Departments have Computing in their title, and a prime forum for communication is known as "The Conference of Professors and Heads of Computing". What I personally find so hard to understand is that some computer scientists are so unfeeling to others in the broader community that they continue to classify all researchers as "computer scientists" as if nothing else matters. So Q: What's in a name or (names)? A: To some people not too much, to others a great deal. 4. Distinctiveness Q: Has SE a unique and recognised identity? Clearly we have - look simply at the job advertisements for the industry. Also, a complete undergraduate programme in SE is just as valid as one in CS and more so than a programme that simply concentrated on databases. However, I would question whether we have progressed far enough in really representing what should be the premier computing discipline in the 21st century. Software Engineering was originally proposed as a radical solution in 1968. Perhaps what we now need is to revisit those radical roots and define a New Software Engineering for a new future. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Articles ###################################################################### Introductory Programming Courses for Software Engineering Students: A Position Statement Rick Duley Edith Cowan University, Perth, Western Australia r.duley@hotmail.com PREAMBLE "Position Statement" is perhaps too pompous a title for this missive - rather, I see it as a Straw Man to be poked with sticks, or perhaps a football to be kicked around. Working, as I do, in extreme isolation it is not surprising that I should develop different ideas from those who work in the mainstream. If I have a different perspective on things, it may just be because I sit atop a different hill. Please read any assertion as though it started with: "In my humble opinion". 1 UNDERLYING PHILOSOPHY Merely dispensing data is not enough. Even computers can hold data. "We have come to believe that information may be enough and that collecting more and more information will do all our thinking for us." This belief is based on the habits established by [Socrates, Aristotle and Plato] is encouraged by school and university. "There was a time when all useful information could be taught. So schools and universities saw it as their job to teach this information. Those days are long gone but schools and universities have not changed much." (Edward de Bono, 1995) The underlying philosophy is that schools and universities will have to change for an information age, if for no other reason because the student body has changed. 1.1 Software Software doesn't exist. Software is a figment of our imagination. People who cannot think cannot imagine. Ergo we cannot teach software development to people who cannot think. 1.1.1 Thought, Perception and Software Development Most students arrive at university without ever having had to think. In their school lives they learnt very quickly that all they had to do was cram sufficient data into short-term memory for regurgitation in an examination and they would pass. This has nothing to do with thinking. In their home lives they were deprived of the joys of making their own toys, playing in puddles and generally making their own fun. After school they either flopped in front of the television, settled down to their playstation, surfed the Net or painted graffiti on a wall. This has nothing to do with thinking. Universities are - or should be - all about thinking. Thinking is a skill. Thinking is a tool. Thinking can be taught. Thinking can be learnt. Thinking is essential to software development - so essential that without it there is no software development. All of the software industry works in a virtual world. Computers are dumb (very fast) adding machines which work only with magnetic fields and electrical impulses - they wouldn't even know noughts and ones if you stuff a bunch of them in the floppy-disc slot. Everything they do, they do because we dreamed it up. If we don't know how we think, how can we think for a computer? This is not to suggest that an Introductory Programming Course (IPC) should be a course in philosophy. However, an IPC must start by opening the eyes of the students to the possibilities and practice of thinking. There is a vast body of work on the subject - the work of de Bono provides readily digestible introductory material. Some may think that it is not the function of an IPC to promote thinking as a skill but somebody must do it. It falls to us, because without that skill, quality software development cannot exist. 1.1.2 Duley's Axiom for Software Development COGITO ERGO EST (I think, therefore it is) 1.2 Engineering I have spent my working life as a tradesman in heavy industry. People's lives have depended, and continue to depend, on what I have done. I know what it is like to check a machine in the morning and sign a book releasing the machine for service knowing that, if it should fail, I could be in court charged with culpable negligence or even manslaughter. Engineering to me is not an academic theory - it is an awesome responsibility. Somehow we must make Software Engineering students aware, at the earliest possible moment, that they are not qualifying for a job, but that they are volunteering for a responsibility, which entails people's lives depending on decisions they make. 1.2.1 Duley's Law Anything that can't go wrong will. 1.3 Software Engineering Software Engineering (SE) is concerned with a disciplined approach to the design, construction and maintenance of software - the creation of accurate and dependable tools and systems in such fields as medicine, transportation, energy, manufacturing and military applications. This is not to say that SE principles and practices are not applicable to the creation of non-mission-critical products such as computer games or short-lived products such as web sites - they are. It is simply the case that licensed software engineers will be more likely to serve in fields where legal liabilities (and insurance companies) demand a high standard of reliability. To inculcate good habits into future software engineers we must, from the very outset, demand total concentration on the job in hand, meticulous attention to detail, sound methods, professional presentation and not a little fatalistic cynicism about possibilities. These are fundamentals of software engineering (and of the traditional engineering disciplines). 1.4 Software Engineering Students Traditional engineering disciplines train people of ordinary talent to produce reliable results. True, students in any intake will have High School results in a high echelon but these are not normally people of genius - the Isambard Kingdom Brunels, Charles Yelverton O'Connors and John Alexander Roeblings of this world are rare indeed. It would be a mistake to assume that SE students will be different. We must, therefore, be prepared to start at the basics, regardless of the level of some of the students. We must start low and aim to finish high. "...software construction requires that forgetful, sloppy and unpredictable people train themselves to be precise and thorough to the point that at least they do not appear to be completely insane from the viewpoint of a very literal computer." Terry Bollinger's Software Construction report in SWEBOK (v0.6) 1.4.1 Effort Software Engineering is an entirely new discipline. It does not have time to grow as did the traditional engineering disciplines. SE educators are involved in creatio ex nihilo (we are making something out of nothing). This requires immense effort. We must expect nothing less from our students if the new discipline is to gain the respect it deserves. 1.4.2 Setting the Bar If students are aware that they can coast along and gain adequate marks from half-hearted efforts, then that's all most of them will do. That's not an attitude which will cover them, or the new discipline of Software Engineering, with glory in the harsh world outside the University gate. We must set a standard sufficiently high that it is extremely difficult to achieve. No one receives an Olympic High Jump Gold Medal by stepping over a rope. Anyone who does gain such a medal wears it with pride. That's the pride we should see in our graduates. 1.5 Programming McConnell's term "code construction" appeals to me as an engineer as being a better description of the actual process of writing code than the simple term 'programming'. It is a systematic process, meticulous and methodical, as is the manner in which any article in concrete or metal is built. Above all, code construction remains central to the whole process of software development - the one part of that process which cannot be ignored. "The ideal software project goes through careful requirements analysis and architectural design before construction begins. The ideal project undergoes comprehensive, statistically controlled system testing after construction. Imperfect, real-world projects, however, often skip analysis and design to jump into construction. They drop testing because they have too many errors to fix and they've run out of time. But no matter how rushed or poorly planned a project is, you can't drop construction; it's where the rubber meets the road." Code Complete, McConnell, 1993 1.6 Introductory Programming There should be no assumption of any prior experience in programming on the part of any first-year student. Inevitably, in a SE course, most students will have prior experience - a fact which may be a source of problems. Self-taught or badly-taught students may be fraught with bad habits which they will have to break if they are to succeed. 1.7 Introductory Programming Courses Inevitably, these units must mention a range of subject matter not directly related to code construction. Some of these are: (a) CMM(R) (Software Quality and the Capability Maturity Model(R), Herbsleb et al., 1997) (b) Ethics (Computer Society and ACM Approve Software Engineering Code of Ethics, Gotterbarn et al., 1999) (c) "Graduateness" (What are Graduates? Clarifying the Attributes of 'Graduateness', Quality Enhancement Group, 1995) (d) Language Design (Abstraction Mechanisms and Language Design Hilfinger, 1983) (e) PSP(SM) (The Personal Software Process(SM) in the Classroom: Student reactions (an experience report). Lisack, 2000) (f) Sexism (Why Women Avoid Computer Science De Palma, 2001) (g) SWEBOK (Bourque & Dupuis, 2000) (h) UML (The Unified Modelling Language User Guide Booch et al., 1998) (R)CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. (SM)PSP and Personal Software Process are service marks of Carnegie Mellon University. This list is by no means extensive and my emphasis is on the word mention. There is simply not enough time for in-depth coverage and such subject matter will be covered in depth in specialised units. Enthusiastic students will have a lot of reading to do. 1.8 Administrivia Using the entire first lecture of any unit to deliver administrative detail is a waste. Recent research indicates that almost all introductory lectures devote at least half the available time to administrivia. Why? Surely we can deal with this problem by having a downloadable document - including a returnable affidavit to the effect that it has been read - to cover the subject and free valuable lecture time. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Obituaries ###################################################################### By: Nancy Mead Norm Gibbs - A Leader in Software Engineering Education Norm Gibbs obtained a Bachelor of Science degree in Mathematics from Ursinus College in 1964 and earned his MS and PhD in Computer Science from Purdue University in 1966 and 1969 respectively. Norm was the 14th student to be awarded a PhD from Purdue's Department of Computer Science. While at Ursinus Norm set a goal to become a professor and upon graduation he accepted a teaching assistantship from the Division of Mathematical Sciences at Purdue University in West Lafayette, Indiana. During his first term he met his wife Barbara (also a TA) in an Abstract Algebra class. Barbara was a secondary school mathematics teacher until their two children were born. She now teaches part time for Ball State's Department of Mathematical Sciences. Their daughter Karen is an Associate of the Society of Actuaries and is employed by Nationwide Insurance in Columbus, Ohio and until recently Jennifer was a systems analyst at BTI (integrated communications provider) in North Carolina's research triangle. Norm's academic career consisted of professorships at Bowdoin College in Maine, Arizona State University, and the College of William and Mary in Virginia. He spent over a decade as the first Director of Carnegie Mellon University's Software Engineering Institute's (CMU SEI) Education Program. During Norm's tenure, the Education Program led the effort to develop a model software engineering curriculum, which is still in use in a number of Masters of Software Engineering (MSE) degree programs throughout the world. He was also named professor of computer science and was the founding director of Carnegie Mellon's professional Master of Software Engineering degree program. He later became Director of SEI's Products and Services Division. He then served as Director of Information Technology and Services at Guilford College in Greensboro, North Carolina. As the College's chief information officer, he took the lead in the redesign and implementation of an entirely new academic and administrative computing environment for the College that leveraged best practices in information technology. Subsequently, he was at the University of Connecticut where he served as Executive Director of the Connecticut Information Technology Institute (CITI) located at the University of Connecticut's Stamford Campus and as professor of Operations and Information Management where he taught courses in e-Commerce Technology. Norm joined Ball State's Computer Science Department as Chair on July 1, 2000, and remained there until he passed away on April 25, 2002. He published numerous articles, edited many publications and has co-authored two books in the Information Technology field. He was a member of the Editorial Board for the Annals of Software Engineering, served on advisory committees and boards, held elected offices in ACM and was a computer science education consultant for colleges and universities throughout the United States. ---------------------------------------------------------------------- On a personal note, I joined the Education Program at the SEI while Norm was Director, and when he became Director of Products and Services, I succeeded him in managing the program. We collaborated on many things during those years, in an attempt to further software engineering education and to forge new directions for the SEI. Norm had a vision for software engineering education, and a dynamic management style. He stood up for his beliefs and worked very hard to achieve them. In each of his professional positions he had major accomplishments. When Norm left the SEI, we continued our professional association and friendship. In recent years, my husband Woody and I enjoyed visits and a number of dinners with Norm and Barb. During his illness, he was again inspirational, demonstrating courage and a positive attitude, as did Barb. One of our fondest memories of Norm was a day last September, when we played golf and went out to dinner. It was great to see Norm looking well and enjoying life, and this is how we shall remember him. For further info, see http://www.cs.bsu.edu/gwen/ngibbs. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### WCRE: The premier conference on reverse engineering theory and practice Papers due: May 15, 2002 (*firm* deadline) http://reengineer.org/wcre2002/ 9th Working Conference on Reverse Engineering / WCRE 2002 Richmond, Virginia, USA 28 October - 1 November 2002 If you are involved in extracting information, artifacts, architectural components (or anything else of value) from existing systems then you should be participating in this conference! The Working Conference on Reverse Engineering (WCRE) is the premier research conference on the theory and practice of recovering information from existing systems. Now in our ninth meeting, we explore innovative methods of extracting the many kinds of information that can be recovered from the data, software, and other components that comprise systems, and examine innovative ways of using this information in system understanding, renovation, and system reengineering. In the last 10 years, there has been considerable progress in this field, centered around WCRE. Reverse engineering has matured and become a part of every practitioner's vocabulary, and student textbook. It now represents a considerable body of knowledge. Increasingly, industry is incorporating reverse engineering tools and techniques into our systems development activities. WCRE plays the leading role in moving this research agenda forward. WCRE is truly a working conference, where discussion is emphasized. By tradition, each paper presentation has a strict 20-minute limit. Following each group of papers on a given topic, there is serious and in-depth discussion of the topic area, the work described in the presentations, and the implications for future research. WCRE attendees are not passive observers; we are active participants in discussing and shaping future directions of the reverse engineering and reengineering fields. Sponsored by: - IEEE Technical Council on Software Engineering / TCSE (IEEE Computer Society) - Reengineering Forum industry association Hosted this year by: - Institute for Data Research - Virginia Commonwealth University ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Ron Haddad Software Engineering Faculty Position Immediate Opening Pennsylvania State University at Erie - The Behrend College School of Electrical, Computer and Software Engineering We are recruiting for a faculty position in Software Engineering beginning August 2002, for the Electrical, Computer and Software Engineering Program at Penn State Erie, the Behrend College. Preference will be given to tenure-track applicants with a Ph.D. in Software Engineering, Computer Science or Computer Engineering. Rank commensurate with experience. Non-tenure-track applicants must have an MS in one of the above fields and significant industrial experience. Individuals must have the ability and commitment to teach the core software engineering curricula, and have the potential to develop a sustainable research program. Areas of interest to the department include: verification, test, reliability, UML, and requirements analysis. Salary is competitive. Penn State Erie (www.pserie.psu.edu) is a growing four-year and graduate college of Penn State, committed to excellence in teaching, research and outreach. The College prides itself on the balance it achieves between teaching and research. The School of Engineering and Engineering Technology has enjoyed substantial and sustained growth, and it has EAC/ABET-accredited programs housed in a modern complex of buildings. Faculty in the School have the opportunity to participate in a number of research and technology-transfer centers and to interact with high-tech companies located in the rapidly-growing Knowledge Park at Penn State Erie. Erie, a metropolitan area of 280,000, is located on beautiful Presque Isle Bay and offers access to a wide variety of sports, recreational and cultural resources. The region is a major industrial, service and tourism center, enjoying a modest cost of living and very affordable housing. It is within two hours driving time from Cleveland, Pittsburgh and Buffalo. Please send, fax or email immediately a complete resume and a brief statement of research and teaching interests to: Ronald J. Haddad Haddad Associates P.O. Box 462 Tarpon Springs, FL 34688 727-939-8078 (voice) 727-934-4322 (fax) rjhaddad@gte.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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@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. -- Managing Editor and Professional Issues Editor 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