Forum for Advancing Software engineering Education (FASE) Volume 9 Number 02 (109th Issue) - February 15, 1999 888 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Omissions Regarding Last Month's Issue This Month's Topic: The Guidelines for Software Engineering Education Next Month's Topic: Software Engineering Body of Knowledge Upcoming Topics News Items IEEE-CS/ACM Education Task Force SE Accreditation Guidelines FASE Archive Additions FASE-TALK Discussion Thread: Company-Based Certification Calls for Participation Student Needs Doctoral Committee Member Software Engineering Course Maturity Survey Position Openings Embry Riddle Aeronautical University Franklin University Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert Omissions Regarding Last Month's Issue Concerning the article "Information Security, Organizational Management and Public Policy" in the January 1999 issue of FASE (Volume 9, Number 1), the following statements should have been included in the text of that article: (R)CERT is registered in the U.S. Patent and Trademark Office. (R)CERT Coordination Center is registered in the U.S. Patent and Trademark Office. Concerning the article "12th Conference on Software Engineering Education and Training (CSEE&T 99) - Complete Advance Program" in that same issue, the following statements should have been included in the text of that article: (SM)PSP is a service mark of Carnegie Mellon University. (SM)Personal Software Process is a service mark of Carnegie Mellon University. The editors of FASE sincerely regret these unintentional omissions. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Tom Hilburn, This Month's Topic: The Guidelines for Software Engineering Education Software Engineering Education - Guidance and Discussion Tom Hilburn Department of Computing and Mathematics Embry-Riddle Aeronautical University hilburn@db.erau.edu In the fall of 1997 the Working Group Software engineering Education and Training (WGSEET - http://www.sei.cmu.edu/topics/collaborating/ed/workgroup-ed.html) began discussion of the need for guidance and support for the development of software engineering education. Since then the Working Group has be working on the development of a document titled "The Guidelines for Software Engineering Education". These Guidelines have the following objectives: * Promote discussion among professionals in education and industry that will improve software education in all institutions at an international level. * Encourage greater commonality in software education within and across computing disciplines. * Provide a coherent, structured description of software engineering concepts, knowledge, and practices, that supports software education curriculum development. * Develop a model curriculum for software engineering that can be applied in whole, or part, to the development of software education programs. Although the Guidelines are not yet complete, they do contain information and guidance that support the above objectives: a description of a software engineering body of knowledge and a software engineering curriculum model. The current version of the Guidelines can be viewed at (http://erau.db.erau.edu/~hilburn/se-educ/guide.html). The WGSEET encourages and solicits comments on the Guidelines (send comments to hilburn@db.erau.edu). This section of FASE includes comments, ideas, opinion, and proposals about the Guidelines and how they relate to various aspects of software engineering education. We are fortunate to have contributions from six people with a wide variety of experience, responsibility, and interest in software engineering education and I believe you will find there efforts beneficial and enlightening. The following is a short summary of the section contents: 1. Robert Cannon, the President of Computing Sciences Accreditation Board, suggests that the Guidelines help to focus attention on the development and accreditation of software engineering education programs and then goes on to describe the developing joint arrangement between CSAB and ABET to accredit software engineering and related computing programs 2. Anthony Cowling, of the University of Sheffield, has been active in the study and development of software engineering education programs. He advocates an SE curriculum model structured around three elements: products, processes, and people. Anthony's contribution describes and discusses concepts and structures that he believes should guide the development of software education programs. In particular he offers suggestions for additions and enhancement to the Guidelines concerning the Foundations Area and the Recurring Area. 3. John Dalbey, of the California Polytechnic State University, concentrates his remarks on the Design Concepts portion of the Guidelines. John describes a model called the Software Engineering apprentice that can used to incorporate some of the Design Concepts presented in the Guidelines (SE in the small, SE in the large, product and process issues, and introducing SE practices in a laboratory environment). 4. Robert Dupuis, of the Universite du Quebec a Montreal, discusses the relationship between the Guidelines and the ACM-IEEE-CS initiative to develop a Software Engineering Body of Knowledge. He proposes and describes a role for the WGSEET and the Guidelines in aiding in the development of academic programs in software engineering. 5. Timothy C. Lethbridge, of the University of Ottawa, discusses the Guidelines in the context of his work in studying industrial needs for SE knowledge and the development of an undergraduate program in software engineering. He suggests that the Guidelines needs to provide more guidance for certain topics and he believes that the Guidelines should distinguish between the various computing and related disciplines. 6. Michael Ryan, of Dublin City University, examines the Guidelines through a dialogue that poses questions about software engineering and then provides answers that elaborate his views on some of the key issues and problems in software engineering education. Michael's answers suggests ways to improve the guidelines by providing additional detail on the purpose of the effort and how it can be implemented. Thanks to all the contributors. Your thoughts and ideas will not only be helpful to WGSEET, but to the entire software engineering education community. ###################################################################### ABET, CSAB and Software Engineering Accreditation Robert L. Cannon Software Engineering Institute Carnegie Mellon University President, Computing Sciences Accreditation Board 1. Introduction The term software engineering has been in use for some time. Relatively few degree programs have been developed, however, and they have been almost exclusively at the masters level. There is no strong agreement on the curricular content or the appropriate level for those programs. That is why the Guidelines for Software Engineering Education are of such great value. Already they can help focus discussion about software engineering education. As they are completed they will help bring about an understanding of the basic concepts, knowledge, and practices of software engineering so that a model curriculum with widespread support can result. 2. Status of Software Engineering Accreditation As yet, no program in software engineering in the United States is accredited by ABET, the entity which will grant accreditation to such programs. ABET has criteria for accrediting software engineering programs, and it is likely that they will be used soon. ABET will grant accreditation at either the bachelors or masters level. It is the policy of ABET that a masters program at an institution is eligible for accreditation only if that institution has no bachelors program in the same area. Thus, for example, an institution offering only an MSE program could have that program accredited, whereas an institution with a BSE and MSE could only have the BSE accredited. ABET criteria for engineering programs are separated into general and program-specific sections. In "Engineering Criteria 2000" (EC 2000) general criteria address 1) students; 2) the educational objectives of the program; 3) program outcomes and assessment; 4) the program's professional component; 5) faculty; 6) facilities; and 7) institutional support. Program criteria address curriculum and additional faculty qualifications in that program. Thus, a software engineering program must satisfy all of the general requirements of EC 2000 as well as those specific to software engineering. Software engineering criteria in EC 2000 are stated only for curriculum. They require that the curriculum must provide both breadth and depth across the range of engineering and computer science topics implied by the title and objectives of the program. The program must demonstrate that graduates have: the ability to analyze, design, verify, validate, implement, apply, and maintain software systems; the ability to appropriately apply discrete mathematics, probability and statistics, and relevant topics in computer and management sciences to complex software systems. ABET program criteria originate with the "lead society" for that program; the lead society for software engineering is the IEEE. Degree programs in engineering are accredited by a commission of ABET, known as the Engineering Accreditation Commission (EAC). Approximately 1,500 programs are accredited by the EAC, using more than thirty separate program criteria. 3. CSAB-ABET Integration In November, 1998 the presidents of ABET and CSAB signed a memorandum of understanding affirming the intent of their boards of directors to integrate their accreditation activities. CSAB is to become a participating body of ABET and will have seats on the ABET Board of Directors commensurate with the number of programs that it accredits. CSAB will be the lead society for programs in computing and also for software engineering. The EAC will continue to accredit software engineering programs, but responsibility for software engineering program criteria will be transferred from the IEEE to CSAB. Other tasks related to software engineering that CSAB will inherit from IEEE include selection and training of program evaluators. A new commission of ABET, known as the Computing Accreditation Commission (CAC) will be responsible for accreditation of computer science and other appropriate areas in computing. The CAC of ABET will be very similar to the Computer Science Accreditation Commission (CSAC) of CSAB. This is no coincidence, as the persons who created CSAB and CSAC more than ten years ago had been involved in ABET and EAC. Expansion of CAC to include other programs in computing is almost certain. Draft criteria for information systems have been prepared and will be presented at appropriate venues during the next year. Unlike the IEEE and almost all other participating bodies of ABET, CSAB is not itself a membership organization. CSAB relies upon the ACM and the Computer Society of the IEEE for financial support and for professional expertise in the recruitment of program volunteers in computer science. This reliance will be even stronger in the future as CSAB takes on the responsibilities of an ABET participating body. Likewise, when CAC begins to accredit degree programs in other computing areas, CSAB will need to have those societies as members in order to draw upon them for criteria definition and program evaluator recruitment and training. As you read this, please remember that ABET, EAC, CSAB, and CAC all rely upon volunteers in their constituent professional societies. Soon we will need some of you as program evaluators. Let us know that you are interested. ###################################################################### STRUCTURING THE RECURRING CONCEPTS IN THE SE CURRICULUM A. J. Cowling, Department of Computer Science, University of Sheffield, England. Both the current draft of the Guidelines for SE Education [1], and the Strawman version of the SE Body of Knowledge [2], are concerned with defining structures for parts of the SE curriculum. Drawing on the model that was used in Computing Curricula 91 [3], they have both adopted a structure which is based on a set of knowledge areas (KAs, from now on), and they have identified a structure for these KAs in which each corresponds to a different stage of the software development lifecycle. This is clearly a sound basis for structuring the main part of the curriculum, and in what follows it will be taken as given. It does not cover the whole curriculum, however, and so all three of these documents have needed to add additional elements to this structure of KAs. This therefore raises the question: what principles should be used to structure these additional elements? In Computing Curricula 91 these additional elements formed a separate structure, which was orthogonal to that of the KAs, so that each of these elements was related to a number of the KAs, which is why they were termed recurring ones. This meant that the overall structure effectively became a two-dimensional matrix, in which one dimension corresponded to the KAs (although actually organised as a two-level hierarchy of Subject Areas and Knowledge Units), and the other dimension corresponded to the recurring elements. Thus, although the curriculum was not documented in this way, one could in principle have constructed for each cell in this matrix a description of how that recurring element was used in that KA. The structure that was defined for the recurring elements had three components, although one of these (Social & Professional Context) is now widely accepted instead as an additional KA [4]. Consequently this component will not be discussed further here, even though in the guidelines it has still been characterised as a recurring concept rather than a KA. Of the other two components, one was described as a set of three processes (viz Theory, Abstraction, and Design), while the other was a set of twelve elements that were explicitly called recurring concepts (viz Binding, Complexity of Large Problems, Conceptual & Formal Models, Consistency & Completeness, Efficiency, Evolution, Levels of Abstraction, Ordering in Space, Ordering in Time, Reuse, Security, and Tradeoffs & Consequences). The relationships between these two components were not clearly defined, however, beyond describing how both recurred throughout the set of KAs, and so there is no obvious principle that could be identified to justify either this structure of two components, or the division of elements between them. Of the two newer documents, the Body of Knowledge defines even less structure for those elements that are additional to the KAs. At this stage in the project of defining it these elements consist simply of the set of topics which did not fit the development stages that are associated with KAs (ie the ones identified in the relevant ISO standard [5]), and so currently these elements are all just categorised as potential KAs. They have been divided into two groups, but this has been done simply by applying to each the criteria that were used for selecting the actual KAs, out of those topics that appeared in the various information sources with which the project started. The current project document gives no suggestions for any further principle which might have been considered for trying to structure these elements further, nor does it go any further in describing how they might relate to the KAs themselves. By contrast, in the guidelines the elements that are additional to the KAs have a much more precise structure, although this includes a number of topics which are outside the core of SE, and so will be ignored for this purpose. The others are then grouped into two components, both of which can certainly be regarded as recurring in the sense that they are clearly orthogonal to the KAs. One of these is a set of three Foundation Components (viz Computing Fundamentals, Human Factors, and Application Domains), and these are intended to underpin the KAs. The other is a set of seven concepts which again are explicitly called recurring ones (viz Ethics & Professionalism, Software Processes, Software Quality, Software Modelling, Software Metrics, Tools & Environments, and Documentation). Even here, though, there does not seem to be any clear principle for defining which components should be classed as recurring and which as foundations. This means that one could, for instance, argue that there are some features of recurring concepts such as Software Processes or Software Modelling which should instead be classed as foundations, or that there are some features of an element such as Human Factors which should be classed as recurring concepts rather than foundations. In the present form of the guidelines there is no firm foundation on which to try to resolve such possible arguments, and this suggests that there is a need for some additional structuring principle or principles, which could be used to justify such classifications of material. The rest of this article is concerned with trying to identify what these additional structuring principles might be, and outline how their application might affect the guidelines. One possible principle could be identified from the terminology used in Computing Curricula 91, which described the recurring elements in terms of processes and concepts. These two terms then suggest a distinction between two kinds of knowledge, viz: 1. Facts, meaning what is known about concepts and the relationships between them; and 2. Intellectual processes, meaning what can be done with that knowledge. Furthermore, this distinction also suggests a relationship between these two kinds of knowledge, in that facts form a foundation for applying intellectual processes, as in the relationships between the different levels of Bloom's Taxonomy [6]. This leads to the structuring principle that, if components of a curriculum are defined in terms of these two kinds of knowledge, then there should be a dependency relationship between those components. Also, the outputs that result from applying intellectual processes would be "higher level" facts, and typically it is these which characterise the KAs. This therefore gives rise to another structuring principle, which is that the intellectual processes should be recognisable by the fact that they do indeed recur throughout the KAs. This basic model of two kinds of knowledge also has a parallel in the distinction that is now commonly made within SE between processes (ways of doing things) and the products or objects which form their inputs and outputs. Indeed, experience of developing an undergraduate degree programme in SE [7] led this author to propose some time ago [8] a model for the structure of the SE curriculum in which the top level has three components that can be described as "the three P's" of SE: 1. Products (the artefacts that are produced as a result of doing SE); 2. Processes (the ways in which these artefacts are produced); and 3. People, who have two roles: (i) as users of the products, who are concerned about their characteristics (functionality, performance, etc), and (ii) as participants in the processes. If one attempts to apply these models to the recurring elements in Computing Curricula 91, then with the benefit of the hindsight that is provided by the last eight years development of SE, it has to be said that the structure does not now seem to be as clean as its authors might have intended at the time. Indeed, what it describes as a set of three processes now appears to be a rather odd selection, since many of the components in them would now be classified as products (ie facts) rather than processes or intellectual activities. Specifically, the theory "process" had four components (viz Definitions & Axioms, Theorems, Proofs, and Interpretation of Results), but only the last of these would now be regarded as a process, while the other three are clearly facts or concepts which are used as inputs to or outputs from the broader activity of "doing" theory. Similarly, the design "process" is defined in terms of components that are as much outputs from activities as activities themselves. Moreover, these activities are precisely the ones which now make up the software development lifecycle, and so form the basis of the KAs for SE. Thus, apart from the interpretation of theoretical results, it is only the components of the abstraction "process" (viz Data Collection, Hypothesis Formation, Modelling & Prediction, Design of Experiments, and Analysis of Results) that would still be classed within SE as intellectual activities rather than intellectual products. Furthermore, as was noted earlier, there is no clear relationship in Computing Curricula 91 between these "processes" and the concepts that it actually described as recurring. Some of them could be described as applications of the "processes": for instance, Binding and Levels of Abstraction could both be regarded as deriving from applications of the activity of abstraction, and the two forms of Ordering could be regarded as arising in a similar fashion. However, this is not the case for all of these concepts, and nor could any of them be seen as foundation concepts on which the "processes" depend, with the possible exception of some aspects of Conceptual & Formal Models. In the case of the guidelines, the structure of the recurring concepts does fit much better with the principles and models that we are trying to identify here, although some modification would be required if they were to fit it completely. For instance, most of the three Foundation Area components are described largely in terms of defining concepts and relationships (ie facts) which will indeed act as foundations for the recurring processes. However, there do appear to be some gaps in this set of foundation concepts, and particularly in respect of the Products component in the proposed top-level structure for SE. Some of the important aspects of SE products are covered by the Foundation Area called Computing Fundamentals, but this mainly deals just with concepts that are drawn from Computer Science, and which could loosely be characterised as "programming-in-the-small". Other aspects, such as the characteristics that identify different kinds of products, are then covered by the Application Domains component. While both of these are significant, though, it can be argued that they are not complete, in that on their own they do not provide a sufficient basis for some of the recurring processes, and particularly those that are concerned with "programming-in-the-large". To fill this gap it is suggested that there are some specifically SE concepts that need to be added to those that have currently been identified as foundations, and these are as follows. 1. Models of systems. Currently models and modelling are defined together in the guidelines as a recurring concept, but the process of modelling depends on certain basic concepts, such as the kinds of models that can be built (viz data models, processing models, etc) and the theories that underlie them, and so these concepts should really be separated out and classed as foundations. 2. Components of software or hardware systems. Some aspects of some components are effectively included within Computing Fundamentals, but their role as components is important for SE, and it should be emphasised by making this one of the foundation concepts. 3. Methods for composing these components to form sub-systems and systems. These are not currently identified, but for SE they are just as important as the components themselves, and so also need to be recognised as foundation concepts. 4. Properties of components and systems. Some aspects of these currently appear in the Software Quality component, but if this is to be viewed as a recurring process then the properties which the quality management process has to try to achieve ought to be separated out as a foundation concept. The recurring process will then link these properties with the relevant foundation concepts from the Application Domains component. By contrast, for People and Processes the structures used in the guidelines fit much more closely with the structuring principles that are being suggested here. The basic concepts associated with People stem from their two roles as users and developers, as defined by the Human Factors component, and so it is obviously correct to classify these concepts as foundations. The set of concepts associated with Processes then provide the basis for identifying the KAs, as described above, with one KA for each stage in the development lifecycle. The important aspect of these stages is that each one can be characterised in terms of products, in that it is concerned essentially with producing some kind of document (in the most general sense) relating to the development of a piece of software. The basic knowledge which characterises each area is therefore concerned with the natures of these output documents, and of the input documents from which they are produced. This knowledge then relates to the particular applications of the various recurring processes which are used in producing these output documents from the inputs. This relationship also helps to clarify the properties of the recurring processes themselves, since they need to be sufficiently comprehensive that, for each stage, it should be possible to regard the activities which must be carried out in creating the products (ie the documents) as particular instantiations of these generic recurring processes. The recurring concepts in the guidelines identify many of these activities, but again it appears that there are some gaps, and that there are some additional processes which need to be added to them. Trying to fill these gaps leads to a set of recurring processes which (including those that are in the guidelines already and those that can be inferred from Computing Curricula 91) is as follows. 1. Modelling. As noted above, this is already identified as a recurring component, but the process aspect of it needs to be separated from the basic concepts that are used in SE models, and which should be classified as foundations. Furthermore, as a process it is arguably one of the most complex ones that a software engineer has to carry out, and as such it can certainly be structured into further components, such as the following five: (i) Analysis (examining a situation and identifying in it the components and relationships that need to be modelled); (ii) Abstraction (identifying levels of detail which are of less importance, and so can be ignored in a model); (iii) Approximation (deciding when a result from a model is accurate enough to be satisfactory); (iv) Application (relating general models to a specific real situation); and (v) Auditing (checking the correctness and appropriateness of each stage in the modelling process). 2. Measurement. This again is already identified as a recurring component, since it is a feature of SE that many of the quantities used in it are not nearly as well defined as they are for other branches of engineering. Consequently it is essential that the underlying principles of defining and measuring these quantities are well understood, so that this process depends on the foundation concept of the properties of components and systems. 3. Evaluation. Currently this activity only appears in the limited context of the Software Processes component, but arguably it is the activity that is involved whenever any form of design or modelling decision is being made, since any such decision will always be based on making some kind of judgement about which design or which modelling approach has "better" characteristics than the others. This suggests that this process needs to be given greater prominence as a recurring activity, along with its dependence on the foundation concept of the properties of components and systems which are used in making the evaluations. 4. Synthesis. Since analysis is included as a recurrent activity (as part of the modelling process), so synthesis needs to appear as well, since ultimately any form of creative activity (such as design) requires amongst other things the synthesis of components into a whole. This process clearly depends on the foundation concepts of components and of the methods for composing them, and it then links with the recurring process of evaluation that is used to determine whether one product which has been synthesised might be better than another. 5. Standardisation. As described above, in order to synthesise things one needs components from which to synthesise them, and methods of composition by which the components can be put together, and these should be defined as foundation concepts. For SE it is important that these components and compositional methods should not have to be invented from new each time, and so it is also important to recognise the activities of standardising and documenting ones that are found to be of particular value. These activities therefore depend on these foundation concepts, and also on the concepts of the different application domains in which particular standards may prove to be useful. 6. Teamworking. Many of the issues that arise as recurring ones within SE do so because SE is primarily carried out by teams of people rather than individuals. An obvious example of this is the need for good documentation, which appears as a recurring element in the guidelines, but insofar as it can be seen as a process it simply reduces to that of recording properly the outputs of the modelling activity. What is important about it is the need to carry it out in a professional fashion, and this arises from the fact that the documents will subsequently have to be read by other members of a team. What is being suggested here is therefore that the activities which make up teamworking should be seen as the recurring processes. The present documentation component itself should then be viewed as the activity of communicating models, which will depend on the various foundation concepts that underlie the processes of modelling and synthesising the products that need to be documented. 7. Automation. In the present guidelines this appears as the concept of Tools & Environments, but the key activities which underlie it are those of automating support for the other recurring processes, and evaluating the tools which embody this automation, and so it is they that should be recognised as recurring processes. In conclusion, what has been proposed is a (hopefully not too drastic) rearrangement of some of the material in the present version of the guidelines, so as to establish much more clearly a structure in which the foundation areas define concepts that underpin the recurring processes, and in which these processes all describe activities that are pervasive throughout the whole of SE, and in particular which are orthogonal to the set of KAs. Space does not permit a detailed evaluation of this proposed new structure, but there are three obvious points which ought to be considered in such an evaluation. The first of these points could be regarded as just an interesting side effect of applying these principles, but in terms of describing how SE links back to Computer Science it does appear to be significant. This point is that, while there was no clear relationship between the recurring concepts in the Computing Curricula 91 and its three recurring "processes", it is now possible to identify each of the recurring concepts from that document as an application of either the foundation concepts or the recurring processes that have been described here. The interested reader is invited to do the exercise of listing each of those twelve concepts and matching it up with the ones presented above. The second point is that this structure of recurring components is meant to be a logical one rather than a physical one. That is, this structure is meant to help the curriculum designer identify the relationships which will need to exist between different course units, as they incorporate the concepts and topics that are identified here. What this structure is not meant to do is identify directly physical components (either foundations or processes) which could be carved out and formed into course units, any more than the KAs or recurring concepts identified by the designers of Computing Curricula 91 were expected to automatically form the basis of course units. The final point is that, while the mere existence of these relationships (which did not hold previously) serves to validate to some extent the structuring principles that have been proposed, the end product of the principles is not just a set of relationships, but a structure for the curriculum itself. This structure will need critical review if its value is to be established, and in particular it will need review not just by academics, but by practitioners as well. Moreover, this review will need to be conducted at a higher level than sometimes occurs, where discussions have a depressing tendency to get side-tracked into issues of "hot technologies" or improving communications skills. These may both be important, but they are not what SE education is fundamentally about. What arguably is at the core of SE education is the teaching of fundamental concepts and the development of the technical transferable skills that build on them, since ultimately these are the things that will last much longer than familiarity with the latest wonder technology. The generic natures of the foundation concepts and the recurring activities which have been identified here suggests strongly that these are the keys to achieving this, since they form the technical transferable skills which distinguish the professional software engineer from the generalist anybody. If this is the case, then for the sake of our students and the profession at large we need to get these recurring concepts and activities right. These guidelines do matter to you! [1] "Guidelines for Software Engineering Education", Draft 14th November 1998, . [2] "Guide to the Software Engineering Body of Knowledge: A Straw Man Version", . [3] A. B. Tucker et al, "Computing Curricula 91: report of the ACM/IEEE-CS Joint Curriculum Task Force", or . [4] C. D. Martin, C. Huff, D. Gotterbarn & K. Miller, "Implementing a Tenth Strand in the CS Curriculum", Communications of the ACM 39.12, December 1996, pp 75-84. [5] "Information Technology - Software Life Cycle Processes", International Standard ISO/IEC 12207: 1995(E). [6] B. S. Bloom (ed), "Taxonomy of Educational Objectives: The Classification of Educational Goals, Handbook 1: Cognitive Domain", McKay, 1956. [7] A. J. Cowling, "The first decade of an undergraduate degree programme in software engineering", to appear in Annals of Software Engineering. [8] A. J. Cowling, "A Framework for Developing the Software Engineering Curriculum", Proceedings of the ACM/IEEE International Workshop on Software Engineering Education, 21st May 1994, Sorrento, IEEE Computer Society Press, pp 111-118, or . ###################################################################### THE SOFTWARE ENGINEERING APPRENTICE John Dalbey, Ph.D. Computer Science Department California Polytechnic State University San Luis Obispo, CA 93407 jdalbey@calpoly.edu We have developed a model for undergraduate programming instruction that we call The Software Engineering Apprentice. This model exemplifies several key "design concepts" from the Guidelines for Software Engineering Education. I would like to summarize the key features that distinguish our model from more traditional instructional models. I hope to emphasize those aspects of our model that may be useful to others designing undergraduate programs in software engineering. The Software Engineering Apprentice is essentially an applied "case study" method for use in programming laboratory activities. In this regard we strongly support Guideline E.1.i. which recommends that students engage in the practice of software engineering through scheduled laboratories. Thanks to a grant from DISA we were able to develop a set of innovative and sophisticated laboratory programming "case studies" to accompany a Fundamentals of Computer Science course sequence. Each case study is a complete software application which demonstrates software engineering methods appropriate for beginning programmers. These case studies are available at no charge to educators and they include specifications, test plans, design documents, and complete source code, as well as guidelines for instructors. Programming assignments in the first course typically are small "throwaway" programs (not part of a larger effort) that are built from scratch without reuse. A number of educators argue that this teaches students a "programming in the small" mentality. Guideline 1.b. suggests that from the beginning of their studies students should be introduced to the importance of software engineering. We argue that students can't see the relevance of software engineering when they are given "throwaway" programs where "hacking" will often be more expedient than software engineering. One metaphor I often use is carpentry school. Most programming labs assign students to build a dog house - they get to bang together the entire product but they don't need to engineer it. We think a better approach is to situate students within the skeleton framework of a real house and let them build small pieces of an pre-engineered product. The Software Engineering Apprentice model is an attempt to create situations where the relevance for software engineering techniques is made apparent even though beginners aren't yet themselves capable of developing large applications. Our approach demands that students work with moderately large pre-existing software applications. Students play an "apprentice" role, participating in tasks found in a real software development environment - testing, code comprehension, maintenance, modification, and enhancement. Our model features both "in the Small" and "in the Large" activities (Guideline 1.c.). The majority of the introductory activities are assignments completed by an individual, but as the students finish their first course they are given team activities to complete. Since our lab assignments are intended to accompany a first course, they feature mostly "product" activities and not many "process" activities (Guideline 1.d.). We do provide some coding standards and an explicit procedure for software maintenance which would fall into the "process" category. But primarily we provide students with "products" that were produced by a hypothetical senior engineer that the students are apprenticed to. The case studies include complete software specifications, test plans, design documents, and documented source code for a fully functioning application. Instead of asking students to develop a trivial program completely from scratch, we ask them to carry out small tasks within the framework of a moderately large (by student standards), prewritten application. The kinds of tasks we give to students mimic those that they might carry out as an entry level programmer in a software development shop - code verification, defect isolation and correction, code modification, and enhancement. In essence our model offers students a chance to learn how software is constructed using a systematic, disciplined approach to software development, yet without demanding "software engineering" topics to be explicitly included in the introductory course. Students will implicitly be presented with "programming-in-the-large" techniques by reading and comprehending pre-existing code. They will see examples of specification and design documentation, test plans, and coding standards. They will see relevant and meaningful application of the language features they are studying, and they will carry out realistic software development tasks. They will be forced to consider how to adapt their solution to a pre-existing framework and thus by implication they will understand the importance of writing code that can be easily reused or modified by others. The lab materials have been "field tested" in CS1 - CS2 courses at California Polytechnic State University and at Cuesta Community College. We found them very easy to integrate into the existing curriculum. Students were able to understand and complete the lab assignments with little external guidance from the instructor. Student self-reports indicate that students found the labs to be valuable in learning to read, comprehend, and modify source code. We also think it is important that students found it motivating to work on programs that could perform some significant task (in contrast to the trivial examples found in most textbooks). A full description of The Software Engineering Apprentice can be found in an article of that title by this author which appeared in the April 1998 issue of Computer Science Education Journal. http://www.swets.nl/sps/journals/cse1.html The materials described in this article are available on the web at http://www.csc.calpoly.edu/~jdalbey/Apprentice/index.html We would like to thank the Ada Joint Program Office and the Defense Information Systems Agency for their funding of the development of these laboratory materials (grant #DCA100-94-1-0004). ###################################################################### The Software Engineering Body of Knowledge and the Guidelines Robert Dupuis (Dupuis.Robert@uqam.ca) Pierre Bourque (Bourque.Pierre@uqam.ca) Alain Abran (Abran.Alain@uqam.ca) Universite du Quebec a Montreal http://www.lrgl.uqam.ca/ There is a joint effort underway from the ACM and The Computer Society (the Software Engineering Coordinating Committee) to establish a Software Engineering Body of Knowledge and a Software Engineering Curriculum, among other activities. We are the co-editors of the Guide to the Software Engineering Body of Knowledge project: SWEBOK (we use SWE instead of SE to avoid any possible confusion with Systems Engineering). From that view-point, we will comment on what role the WGSEET could play and where the guidelines could be most useful. The general issue is that of translating the guide to the SWEBOK and the standard curriculum into practical curricula, teaching practices, tools, etc. The Computer Society/ACM initiative should result in a widely accepted Guide to the Software Engineering Body of Knowledge (www.swebok.org) and a Standard Curriculum. There is a clear distinction between the two: the SWEBOK project covers only the Knowledge and not the Curriculum itself. The list of knowledge areas and components included in the guidelines would have to be adapted to the results of both these groups. So far, we know that the contents of the SWEBOK will be somewhat similar to the list included in the guidelines. This is not surprising. We can expect these lists to share a large overlap. So, there is no major problem on this point. The SWEBOK will include, in its first version, the core knowledge, the 'generally accepted' that is expected from a graduate with four years of experience. That leaves out what can be labeled as 'advanced' knowledge, but also 'specialized' knowledge (knowledge used mainly in a field like real-time systems) and application domains. In these two categories, much has to be done to determine what should be included in the teaching. But, assuming that these efforts are successful and the expected results are published, the problems of teaching Software Engineering re far from over. It seems to us that the main problem is the translation of all these standards, Body of Knowledge, best practices into knowledge and more importantly, competencies for graduates. That is where a group such as the WGSEET becomes necessary. In the spirit of the more open rules of accreditation of the ABET, we, as teachers, have to try various solutions to these problems, but these experiences are useless if we cannot valuate them and share them. A second problem is: how do we distribute within the curriculum what is called the 'recurring' knowledge components in the guidelines? For instance, 'tools', 'metrics' and the like have to be covered somewhere. But part of it is general, and deserves a separate section, while some aspects are so specific to some life-cycle steps for example, that they have to be discussed there. This problem is not clearly resolved in the guidelines. A solution will be adopted for the guide to the SWEBOK. What is needed then is a solution at the curriculum and teaching level. We believe the guidelines should develop discussion of that problem. A third problem comes from the treatment of 'related disciplines', called 'Foundation Areas' in the guidelines. The SWEBOK and Curriculum projects will propose a list of such disciplines, along with knowledge areas to be covered within each. These will be chosen from well established list of knowledge areas. For Computer Science, the list will be taken from the Curriculum 2001 project. For Project Management, the document is the Project Management's Institute Guide to the Project Management BOK (available at www.pmi.org). We think that the guidelines should address this issue. We think that the Working Group on Software Engineering Education and Training, because of its interest and experience in the field, can very well fill that gap between the theoretical curriculum and the implementation considered by individual universities. ###################################################################### An Analysis of the Guidelines for Software Engineering Education Timothy C. Lethbridge SITE: School of Information Technology and Engineering University of/d'Ottawa Ottawa, Canada, K1N 6N5 www.site.uottawa.ca/~tcl | tcl@site.uottawa.ca/T.Lethbridge@ieee.ca I present the following comments regarding the draft "Guidelines for Software Engineering Education", produced by the Working Group for Software Engineering Education and Training and available at http://erau.db.erau.edu/~hilburn/seeduc/guide.html I will simply refer to these as the Guidelines in what follows. The input I provide arises from several experiences: * Designing the software engineering program at the University of Ottawa (http://aix1.uottawa.ca/academic/info/calendars/gng/seg- en.pdf). This program now has students in their second year, and was one of the first to be approved in Canada. Several factors influenced the design of the program, including: a) what our research told us is needed in industry, b) what we had to do to mesh with other engineering and computer science programs at the university, and c) what we needed to do to ensure accreditation by CEAB (www.ccpe.ca), the Canadian body that corresponds to ABET in the US. Another interesting point about our program is that it is taught by our School of Information Technology and Engineering (www.site.uottawa.ca), which is a complete and very successful amalgamation of original computer science and computer engineering departments -- a model I recommend other universities follow. * Two surveys I conducted where I asked practitioners questions about how important various topics have been to them in their software engineering careers, as opposed to how much they learned about the topics in their education. The results from these surveys provide concrete evidence that some topics are over-taught, and other topics are under-taught in universities. Data from my 1997 survey is available as "A Survey of the Relevance of Computer Science and Software Engineering Education", 11th IEEE Conference on Software Engineering Education and Training, Atlanta, as well as at http://www.site.uottawa.ca/~tcl/edrel More detailed results will soon appear in a special issue of Annals of Software Engineering http://manta.cs.vt.edu/ase/vol6Contents.html). In the following comments I will provide some highlights of the 1998 survey which was more international in scope, and had improved questions. I have submitted articles about this latest survey to refereed publications. * Reviewing guidelines proposed by the Canadian Information Processing Society (www.cips.ca). The objective is to use these for accrediting software engineering programs offered in Canadian computer science departments (a completely distinct process from CEAB accreditation). Now to my comments about the Guidelines. First of all, I feel that the structure of the document is excellent. I especially like the structure of the body of knowledge in section D. My comments will suggest three main kinds of changes: 1) Providing more guidance as to the depth of coverage of various topics; 2) providing guidance about the similarities and differences among software engineering, engineering in general, computer science and computer engineering; and 3) a minor change in terminology. 1. Although the guidelines as they stand give good guidance about *what* should be taught, I feel there is not yet enough information to help curriculum designers decide *how much* of each topic to teach. I think almost all of the topics listed in section D are at least touched upon by many computer science programs. For software engineering programs, however, a certain set of these topics need to be given extensive coverage. I don't envision that the Guidelines should dictate specific numbers of hours for each topic, however it would be useful if they could suggest minimums (and, by the way, these should not be set as 'fractions' of the program since that forces many changes whenever the total size of the program is increased or decreased). The question then arises: How should the curriculum designers decide on the minimum number of hours to recommend, and for which topics should this minimum be given? One way of doing that would be to look at coverage in existing computing programs, and then calculate reasonable minimums based on whether the topic seems to be over-taught or under-taught. The following three tables give data from my 1998 survey that might help make this assessment. The topics listed in the tables are taken from a set of 75 topics that are either compulsory material or else frequently-taken electives in computing programs. Note that a topic does not necessarily correspond to a single course, and there is not an exact correspondence between these topics and those in the Guidelines. The first table lists the 20 topics considered most important by the almost 200 software professionals in the survey. It would seem reasonable to ensure that software engineering programs have minimum coverages of these. It is particularly interesting to note the presence of non-technical topics on this list. (1) Specific Programming Languages (2) Data Structures (3) Software Design and Patterns (4) Software Architecture (5) Requirements Gathering and Analysis (6) Object Oriented Concepts (7) Human Computer Interaction and User Interfaces (8) Ethics and Professionalism (9) Analysis and Design Methods (10) Giving Presentations (11) Project Management (12) Testing, Verification and Quality Assurance (13) Design of Algorithms (14) Technical Writing (15) Operating Systems (16) Databases (17) Leadership (18) Configuration and Release Management (19) Data Transmission and Networks (20) Management The second table gives the 20 topics from the bottom of the same list. Curriculum designers might consider eliminating these topics from the mandatory requirements for software engineering programs. I have flagged with an asterisk those courses where doing that might be somewhat contentious. Of particular note is calculus, which is found very low in the list (67th out of 75): I note that the Guidelines include discrete mathematics and do not list calculus, however explicit mention of such omissions might be helpful so people do not think it was left out by accident. I will return to this issue later. (56) * Linear Algebra and Matrices (57) Philosophy (58) Second Language other than English (59) * Physics (60) Information Theory (61) Graph Theory (62) Queuing Theory (63) Computer Graphics (64) Digital Signal Processing (65) Control Theory (66) Pattern Recognition / Image Processing (67) * Differential and Integral Calculus (68) Combinatorics (69) Artificial Intelligence (70) Analog Electronics (71) Laplace and Fourier Transforms (72) * Differential Equations (73) * Chemistry (74) Robotics (75) VLSI Finally, the next table shows the 10 topics where the 'knowledge gap' is greatest; i.e. where there is the greatest difference between the importance of a topic and the amount learned in university or college. These are topics where traditional programs have been most inadequate so software engineering programs might well mandate minimum coverage of them. (1) Configuration and Release Management (2) Negotiation (3) Human Computer Interaction and User Interfaces (4) Leadership (5) Ethics and Professionalism (6) Project Management (7) Requirements Gathering and Analysis (8) Maintenance, Reengineering and Reverse Engineering (9) Software Cost Estimation (10) Process standards such as CMM(R) / ISO 9000 etc. [Note: (R)CMM is registered in the U.S. Patent and Trademark Office.] 2. I think the guidelines should provide some help to curriculum designers who must wrestle with the issue of how to have their program accepted as an "engineering" program. This requires negotiation and compromise with two sets of stakeholders: The professional engineering establishment (who are interested in accrediting programs that meet their conception of engineering and software engineering) and certain university administrators and colleagues (who also have their view of the fields, and want new programs to mesh with old). To aid in these negotiations, I think the Guidelines should try to lay out the following clearly: * In what ways is software engineering like, and unlike, other branches of engineering? * What is the boundary between software engineering and computer engineering? * What is the boundary between software engineering and computer science? Different people will offer different answers to these, hence there will be controversy if they are added to the guidelines. However that is not good enough reason for their absence: Many points in the document will be controversial, and the answers do not have to be dogmatic or overly-detailed. I suggest a framework for possible answers below: I can answer the second and third questions rather easily: The biggest differences between SE and CS or CE ought to be based on the emphasis given to particular sets of topics. I think that all three types of programs would cover most of the material in the Guidelines. Software engineering programs would place more emphasis on the 'core' areas in the document (requirements, design, project management etc.). Computer Science programs would place more emphasis on the foundations' areas, particularly computing fundamentals and specific software technologies (see my comment on terminology at the end of this review). Computer engineering programs would, like software engineering, put heavy emphasis on the 'core' areas, but with the word 'software' replaced by 'computer system'. Computer engineering programs would also need some electronics, and hence prerequisite material in calculus and physics. The first question -- how does software engineering compare to other branches of engineering -- requires a longer answer. However, as with the other questions the Guidelines provide a nice framework for an answer. The body of knowledge (section D) nicely lists a set of categories that can almost entirely be applied to the whole of engineering, if the word 'software' is removed: All engineers, not just software engineers, have to be concerned with the knowledge categories defined as 'core': Requirements, design, project management and evolution. They all also have to be concerned with foundations in human factors, fundamental sciences, etc. The recurring issues of ethics and professionalism, processes, quality modeling, metrics, tools and environments apply to all areas of engineering. And finally, all areas of engineering require education in supporting areas such as mathematics, natural science and business. How then does software engineering differ from other engineering disciplines? I think that the best way to think about this is to consider the constraints placed on designs: a) The constraints imposed by basic science are different. Other branches of engineering are heavily based on physics. Physical laws bear heavily on design parameters and decisions, thus students in these branches of engineering must know a lot of physics. In contrast, very few software engineering design decisions are constrained by physics. That is not to say that computers are uninfluenced by physics, just that software engineers are working at a higher level of abstraction; they are plying their trade using tools (computers) where the physical constraints have already been dealt with at lower levels. b) The constraints imposed by mathematics are different. Continuous mathematics is used extensively in other branches of engineering to make design decisions. Not so in software engineering where logic and other areas of discrete mathematics are needed. c) The constraints imposed by construction are different. In other branches of engineering, designers must constantly think, can we build this? In software engineering the effort required to take a design (i.e. a program) and produce multiple functioning copies of it is minuscule compared to the design effort (where programming is really just low-level design - see my comments about the use of the term "construction" below). d) The constraints imposed by potential complexity are different: Differences 1 and 3 above make the potential for escalating complexity a far greater concern in software engineering than in other engineering disciplines. e) The constraints imposed by human factors are different. All engineers have to consider ergonomics and to account for the needs of users. However differences 3 and 4 means that software engineers can rapidly create software with huge numbers of features. The viability of the software comes to rest to a huge extent on its usability and on the ability of other software engineers to understand it later These differences in constraints ought to cause a considerable shift in software engineering education away from traditional engineering education -- but that does not mean that SE is not engineering. It also must be said that software engineers will sometimes face design constraints deriving from physics, continuous mathematics, construction etc. However, these constraints will only be faced in certain application domains, not every day -- thus education in this material should be elective, or at least non-core. I believe that if distinctions like the above were carefully presented to engineering faculties and accreditation bodies, then curriculum developers could more easily justify making decisions that are currently impossible in many universities -- e.g. replacing calculus, chemistry and physics in first year with discrete mathematics and studies of human factors. The Guidelines seem like an excellent place to put this information. 3. As final comments, I will propose two terminology changes to the Guidelines. I have never liked the term 'Software Construction' that is used both in section D.1, the body of knowledge, and in section E.3.e, the curriculum model. I don't think there is a good analogy between what goes on in the software world and the construction of, for example, bridges, computers, and cars. The term software construction is used to refer to the low level details of implementation (mostly programming), however I feel that this is just a kind of design. Recommendation: Change the term 'Software Construction' to 'Program Implementation', 'Low-Level Design' or something like that. I also think the term 'Application Domains Component' as used in section D.2.c is misleading. Before reading it, I thought it would refer to topics such as business, science or engineering that students have to learn so they can converse with clients and develop requirements. In fact what is meant here are computing technologies such as databases and graphics that are used to develop software for certain application domains but not others. I think it would be better to call section D.2.c 'Specific Software Technologies Component' or something similar. Conclusions: These guidelines will be an excellent reference when complete. My recommendations are: 1) Provide more guidance about the emphasis required for certain topics; 2) Highlight similarities and differences with related fields; and 3) Fix a few minor terminology problems. ###################################################################### Software Engineering Education - some comments on the draft Guidelines Michael Ryan Dublin City University, Ireland Michael.Ryan@dcu.ie First, thanks to Tom Hilburn and to FASE for the opportunity to put forward the points below, and also for their tolerance in giving them a hearing. Second, I think the Guidelines for Software Engineering Education is an excellent document, and I look forward to seeing it fleshed out in greater detail. Third, there are questions not fully covered in the Guidelines at present which are worth considering. I try to develop some of them below. Question 1 : Why bother to teach Software Engineering? The Introduction gives some excellent reasons, but maybe there are others we should mention. Reason #1 : Because it's interesting Software engineering gives us the most powerful and flexible methods for developing systems that have ever existed. Its scope and capabilities are extraordinary. Its limitations are based upon profound results in logic, complexity and management. It is a fascinating and challenging subject, well worthy of study in its own right. Reason #2 : Because it's educational It is deep rather than superficial. It requires thorough analysis, creativity in design, and a disciplined professional approach. It involves ability in logic, computation, complexity, information storage and retrieval, communications, mathematics and statistics, HCI, and quality assurance. To support the broad breadth of applications it requires a basic understanding of technology and of business practices. The understanding, skills and discipline acquired as part of a software engineering education are widely transferable, and of value even if the student moves to a totally different career area. In terms of personal development the study of software engineering is as educational as the study of other more traditional disciplines. As educators, the justification in educational terms for what we do is as important as the needs of industry or of society as a whole. We are after all in the business of educating people, as well as meeting society's needs for knowledge and skills. The study of Ancient Egypt can be justified on educational grounds, and we should be prepared to do as much for software engineering, as well as stressing its importance to society. Otherwise we sell our subject short. We are fortunate that software engineering is very educational. Maybe the Introduction could include an educational justification as well as the excellent needs based one it already contains. Question 2 : What is the output? What do we mean by a 'software engineering graduate'? In one way, the planned addition of curricula and courses to the Guidelines will answer this question. In another way, the answer to this question might be seen as a prerequisite, setting the target which the curricula and courses are trying to hit. Taking the second point of view, it might be worthwhile to give an explicit description of what we are trying to produce, stated in fairly general terms. There is a very thorough description already of the body of knowledge associated with software engineering in the Guidelines, but this is not the same as a description of a graduate software engineer. A possible answer might be along the following lines (I'm sure much better versions are available) 'The graduate is prepared for a professional career as a software engineer. The course includes a theoretical treatment of appropriate topics in computer science and software engineering, treatment of professional and managerial issues and practices, development of skills in analysis, design, programming, and quality management, and a knowledge of technology and business. As well as professional software engineering, careers include research in software engineering, research in computer science, and careers associated with the development and use of Information and Communications Technology The understanding, skills and discipline acquired as part of the degree are widely transferable, and of value even if the graduate moves to a totally different career area'. Question 3 : What is the role of industry? What should academia not do? It's probably fair to say that no academic course can turn out a professional anything. A further period of internship, or articles, or other traineeship is required, and there are usually clear arrangements for the provision of this by the industry or profession. In addition, there may be requirements for on-going education to retain professional status, and again this is typically organised by the profession. In software unfortunately there are no clear standards for such professional internship. Academia tries to fill the gap, by for example simulating as realistic an industrial environment as possible (or perhaps an unrealistically idealised one). As the Guidelines evolve, it might be helpful to include suggested roles and objectives for the academic and industrial partners in the professional formation of the graduate. This would identify certain aspects of the software engineering education which should not be attempted by academia, or perhaps only as a last resort, and of course vice versa, and might help in setting up relationships between colleges and industry. Question 4. What is the intake into the course? What do they already know? How many? What do they already know? Once, we could assume they knew nothing about software development. Now, it's hard to know, some may have worthwhile skills. It would be great if we could get to a stage where the student intake to software engineering would have a reasonable knowledge of problem solving and programming 'in the small', which we could revise rapidly and then build on. However, introducing computing as a subject at second level (i.e. high school) has its perils - in some countries this has been followed by a major decrease in numbers applying to study the subject at third level. It may be outside the brief of the Guidelines, but perhaps we should think a bit more about what is happening in computing education at second level. Particularly since if students are put off at that stage, or taught badly, the impact on third level will be significant. In many countries places on computing/software engineering courses are not filled (Ireland is an exception, and does not have computing as a second level subject). If most students are starting from scratch, then their problem solving and programming skills 'in the (very) small' will need a lot of time. It is easy to forget how hard it can be to get the knack of writing even very simple programs for very simple problems. If we skimp on this, we'll end up talking about writing a concerto for orchestra to students who are frightened of writing a tune for a tin whistle. We might perhaps apply a mastery learning approach, with a very high pass mark, and use the technology to help us through self paced learning and automatic assessment. (cf www.compapp.dcu.ie/~cdaly/roboprof) A section on Teaching and Assessment Methodology in the Guidelines with pointers to successful practice might be useful. How many? If the quantity is right, if for example the staff-student ratio allows a good level of interaction between teachers and students, all kinds of other difficulties can be overcome. However, the pressure to increase student numbers combined with difficulties in finding appropriate staff and in keeping facilities up to date can lead to a poor level of support for students. This in turn can lead to unacceptable failure and drop out rates, and put standards in danger. In time, perhaps the Curriculum Support section of the Guidelines could consider staff quantity as well as staff quality, and perhaps provide some guidance on the staffing levels likely to be needed, and some pointers to places that seem to have got it right. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [reprinted from the January 1999 issue of FASE] From: Robert Dupuis Pierre Bourque Universite du Quebec a Montreal Next Month's Topic: Software Engineering Body of Knowledge Guide to the Software Engineering Body of Knowledge: Stakeholder Issues and Intended Usages Software engineering has not reached the status of a legitimate engineering discipline and a recognized profession. Achieving consensus by the profession on a core body of knowledge is a key milestone in all disciplines and has been identified by the ACM and the IEEE Computer Society as crucial for the evolution of software engineering toward a professional status. Currently ongoing is a joint IEEE-CS/ACM project designed to reach this consensus and to develop a Guide to the Software Engineering Body of Knowledge. This Guide will seek to identify and describe that subset of the body of knowledge that is generally accepted or, in other words, the core body of knowledge of the discipline. The preliminary Knowledge Area descriptions will be reviewed from various stakeholder viewpoints. So far, the editorial team has identified the following viewpoints: industry alignment, usefulness to practitioners, curriculum development, professional training, university teaching, coherence with standards, software engineering licensing, legal issues and student needs. Contributions for the March Issue of FASE are being solicited on: - What your expectations are in this regard, which viewpoints should be adopted, and, within each viewpoint, what issues are critical? In other words, what are the uses that you see for the Guide to the Software Engineering Body of Knowledge? Contributors should see www.swebok.org for: - A short project overview; - The Straw Man version of the Guide to Software Engineering Body of Knowledge; - A Presentation on the current Stone Man phase. Your contributions should be sent to either: Robert Dupuis Director, Graduate Studies in Software Engineering Universite du Quebec a Montreal Dupuis.Robert@uqam.ca ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming Topics TBA: Clients, Students, and Projects Guest Editor: Susan A. Mengel Texas Tech University For more information about a particular issue's topic, please contact the corresponding guest editor. Please refer to the article format provided at the end of each issue when making submissions, which are always made directly to the guest editor. Here are some possible topics for future issues: * Accreditation * CASE Tools * Curriculum Models * Distance Learning * Software Process Improvement Education If you are interested in being a guest editor for any of these topics, or have any suggestions for future topics, please contact me at bagert@ttu.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### From: Bruce Barnes IEEE-CS/ACM Education Task Force SE Accreditation Guidelines Below is the final draft of the Software Engineering Accreditation Guidelines. Both the ACM and the IEEE-Computer Society have approved the report. It has been forwarded to ABET for their use. [Editors Note: See the article "ABET, CSAB and Software Engineering Accreditation" in the "This Month's Topic" section for more on the current status of software engineering accreditation.] ____ ACCREDITATION CRITERIA FOR SOFTWARE ENGINEERING UNDERGRADUATE PROGRAMS Education Task Force of the Joint Steering Committee of the IEEE Computer Society and ACM for the Establishment of Software Engineering as a Profession Gerald L. Engel and Richard J. LeBlanc, Task Force Co-Chairs INTRODUCTION As part of the efforts of the Joint Steering Committee of the IEEE Computer Society and ACM for the Establishment of Software Engineering as a Profession, an Education Task Force has been established. Members of the Task Force are as follows: Bruce H. Barnes, IEEE/CS Representative Gerald L. Engel, IEEE/CS Co-Chair Martin L. Griss, ACM Representative Richard LeBlanc, ACM Co-Chair Tony Wasserman, ACM Representative Laurie Werth, IEEE/CS Representative This Task Force has been charged with the development of model software engineering education programs based on the initial work of the Task Force on the Body of Software Engineering Knowledge (March 27, 1997). More information about the work of the Joint Steering Committee can be found at the following URL: http://www.computer.org/tab/seprof/ The first effort of the Task Force has been the development of draft accreditation criteria for undergraduate programs in software engineering. We have not done so primarily to support the creation of an accreditation mechanism for such programs. Rather, accreditation criteria are, in effect, a specification which is implemented by each curriculum that meets their requirements. It is our intention to use these criteria as a specification for our work on the development of a model undergraduate program. The Task Force is now proceeding with development of a model software engineering curriculum that meets these accreditation criteria. Based on the interim report of the Task Force on the Body of Software Engineering Knowledge, it is also anticipated that similar efforts in the area of software engineering technology, graduate programs, and continuing education programs will be developed. Gerald L. Engel Richard J. LeBlanc Co-Chairs, Software Engineering Education Task Force ---------------------------------------------------------------------- ACCREDITATION CRITERIA FOR SOFTWARE ENGINEERING (revised 9/25/98) PREAMBLE Graduates of an accredited program must demonstrate the ability to analyze, design, verify, validate, implement, and maintain software systems, using appropriate quality assurance techniques/methods in all of these. Graduates must understand and use appropriate processes, models and metrics in software development. They must possess the necessary team and communication skills to function in a typical software development environment. The following requirements are intended to provide a specification for software engineering programs that produce students meeting these objectives. FACULTY REQUIREMENTS The quality of the program is primarily dependent on the faculty. There must be sufficient faculty to provide course offerings that allow the students to complete the program in a timely manner, and provide direction and guidance to the students and to student teams. There must be sufficient full-time faculty to oversee the program as a whole, as well as the individual courses. The interests and qualifications of the faculty must be sufficient both to teach the necessary courses, and to plan and modify the curriculum. The faculty must be able to interact effectively with software practitioners. Faculty members teaching core software engineering courses should have substantial practical software engineering experience. Teaching loads must be reasonable, and consistent with the program objectives, and the institutional expectations for research and professional development. Loads should also be consistent with other disciplines requiring significant project and laboratory work. Mechanism must exist to insure the professional growth and development of the faculty, as scholars, as educators, and as software practitioners. CURRICULUM Software engineering encompasses theory, technology, practice and application of software in computer-based systems. A central theme of the curriculum is to engender an engineering discipline in students, enabling them to define and use processes, models and metrics in software and system development. The curriculum integrates technical requirements with general education requirements and electives to prepare the student for a professional career in the field, for further study, and for functioning in modern society. The program must include approximately equal segments in software engineering, in computer science and engineering, in appropriate supporting areas, and in advanced materials. This material should cover about three-quarters of the overall academic program, with the remainder to include institutional requirements and electives. The software engineering portion of the program covers processes and techniques for developing and maintaining large systems. Courses should address the areas of requirements analysis, software architecture and design, testing and quality assurance, software management, selection and use of software tools and components, computer and human interaction, maintenance and documentation. Substantial design work must be included and the students must be exposed to a variety of languages and systems. Engineering responsibility and practice must be stressed, which includes conveying ethical, social, legal, economic and safety issues. These concerns must be reinforced in advanced work, as must the appropriate use of software engineering standards. Students should also learn methods for technical and economic decision making, such as project planning and resource management. Additionally, students must achieve an understanding of the need for and an ability to engage in life-long learning. The computer science and engineering portion of the program must include the areas of algorithms and data structures, computer architecture, databases, programming languages, operating systems, and networking. The computer science principles in these areas should be integrated and applied in advanced software engineering courses and projects. Included in the appropriate supporting areas are communications (oral, written, listening), including the abilities to work in teams, and mathematics focusing primarily on discrete mathematics and probability and statistics. The advanced portion is designed to meet the objectives of the program by providing depth in one or more areas. This part of the program may incorporate further study in the software engineering and computer science topics indicated above, may involve work in additional areas of theory or technology, and should include work in one or more significant application domains. Particular domains may require additional work in supporting areas such as mathematics and science. The program must address all aspects of software development and maintenance, and provide experience in a realistic team environment. These notions should be integrated throughout the program, which must incorporate a meaningful major project that integrates many aspects of the curriculum. LABORATORY AND COMPUTING RESOURCES The program requires substantial laboratory and computing resources for class work, individual projects, and team projects. These resources will normally involve a blend of computing facilities including workstations and communication facilities as well as resources for bulk data storage and printing. Sufficient facilities must be available so that all students have adequate and reasonable access to the appropriate system for each course, and for communicating with other students and faculty. Adequate facilities must also exist to support the work of the faculty. In addition to access to a variety of languages, operating systems, and database systems, it is essential to have access to commercial tools supporting various software development tasks. Appropriate licensing arrangements are necessary to insure that students have access to these resources. In addition to software laboratories, which include clusters of computers and licensed software, there are needs for meeting space to support team projects. Support services are required at a variety of levels including hardware maintenance, programming, software maintenance, systems management, documentation, and instructional training. The number of support staff with primary responsibility to the program must be consistent with the stated objectives of the program. A functioning laboratory plan addressing hardware and software development, acquisition, management, and maintenance must be present. STUDENTS The quality of a program is dependent on the quality of the students, as well as the faculty and institutional resources. There must be established standards and procedures to insure that graduates of the rogram have met both the requirements and the objectives of the programs so that they have the requisite qualifications to function effectively as software practitioners. In addition, there must be sufficient students enrolled in the program to insure that realistic projects and activities can be included. It is the responsibility of the faculty to facilitate and monitor the progress of the students. Appropriate measures, consistent with the institutional mission and program objectives, must exist to guide students toward completion of the program in a reasonable period of time, and to evaluate the success of the graduates in meeting the program objectives. INSTITUTIONAL SUPPORT A. The organizational structure, fiscal policies, and instructional philosophy of an institution must assure that an accredited program will maintain its quality. Areas of institutional support that are considered especially important include the following: 1. Faculty Support Many factors affect faculty recruitment and retention. Sabbatical and other leave programs, reasonable teaching loads, and competitive salaries are important in attracting and retaining faculty of high quality. There must be sufficient support to allow faculty members to attend national technical meetings with sufficient frequency to maintain competence as teachers, scholars and practitioners. There must also be support and recognition of scholarly activities. The advisory function of the faculty must be recognized by the institution and must be given appropriate administrative support. 2. Administration All levels of administration are relevant to the program. Positive, constructive leadership at the college/school level and in the unit that administers the program are especially important in maintaining the program quality. Adequate time must be assigned for the administration of the program. Upper levels of administration must provide the program with the resources and atmosphere to function effectively with the rest of the institution. 3. Library The faculty and students in the software engineering program must have access to appropriate media resources, supported by professional information specialists who can assist in finding necessary materials in a traditional library collection or on the Internet. The technical collection must provide appropriate access to up-to-date texts, reference works, and publications of professional and research organizations that are relevant to the program, including conference proceedings, newsletters, technical reports, and trade publications. 4. Support Services The institution must provide modern office equipment such as word processors and duplicating equipment. In addition, administrative support must be consistent with the type of program and level of scholarly and practitioner activity. B. Assessment of Program Effectiveness The effectiveness of the program must be evaluated on a regular basis. This evaluation must be documented, and information gained through this activity should be seriously considered as improvements are made in the program. Formal evaluation mechanisms must be part of program administration (for example, an advisory board of active software practitioners meeting with the program faculty at regular intervals). Effectiveness measures should also include monitoring of student placement experience and tracking the professional development of students. ###################################################################### By: Don Bagert (FASE Archivist) FASE Archive Additions The FASE web page has recently been modified so that a complete table of contents is now available in both chronological order (starting with Volume 1, Number 1) and reverse chronological order (starting with the current issue.) Thanks to Jochen Ludewig for making this suggestion. ###################################################################### From: Don Bagert FASE-TALK Discussion Thread: Company-Based Certification I have recently started a discussion thread on FASE-TALK regarding my concern over company-based certification programs, especially those that use the term "engineer" in the title. If you are interested in this discussion, you can subscribe to the FASE-TALK listserv by writing to and, in the text of your message (not the subject line), write: subscribe fase-talk ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Keith Pierce Student Needs Doctoral Committee Member One of my former students is pursuing a doctorate at the Union Institute, which offers the degree via distance learning. He wants to write a thesis in the area of software engineering education. He needs to find a doctoral committee member who can help in this area. The following email excerpt describes his needs. Undoubtedly a vast majority of FASE subscribers meet the qualifications. Interested persons can contact me, and they can find out more about the Union Institute at their web site, www.tui.edu. Thanks, Keith Pierce ___ Do you have suggestions for individuals who fit the qualifications for my committee? They must hold a Ph.D., preferably in CS, and must have excellent knowledge in Software Engineering (and preferably SE Education). College education knowledge/experience is a definite plus...and, I would probably say, a requirement. ###################################################################### From: Chi Heng Ng Software Engineering Course Maturity Survey We would like to invite FASE readers to provide some input to our online survey concerning the assessment of the maturity level that software engineering project courses are taught in universities. The project is undertaken by chi heng Ng, a graduate student at Arizona State University, under the supervision of Dr. James Collofello of the Computer Science and Engineering department. Since its introduction in 1987, the SEI Software Process Maturity Model has become a defacto standard for assessing and improving software processes. The overall goal is to help an organization to identify the key practices to increase the maturity of its software development process. Our work attempts to develop an analogous, but highly simplified process maturity framework applicable to software engineering project courses at either the undergraduate or graduate level. The results from our survey will be used to provide statistics on the different maturity levels of courses encountered in the responding institutes. The exercise of completing the assessment should also provide individual instructors with ideas on where they might improve their projects. The URL is http://public.eas.asu.edu/~ngchi Looking forward to your input. Thanks. chi heng Ng ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Tom Hilburn, FACULTY POSITIONS AT EMBRY-RIDDLE Applications are invited for faculty at the Department of Computing and Mathematics of Embry-Riddle University in Daytona Beach, FL. Appointments are available for tenure track, non-tenure track, and visiting positions beginning Fall 1999. The Department offers two undergraduate programs: in Computer Science with the emphasis on Software Engineering and in Computer Engineering, and two graduate programs: in Software Engineering and in Industrial Optimization. The curriculum and research projects have an applied science focus and emphasize software development process in a real-time safety critical environment. The tenure track position is for teaching/research and requires a Ph.D. in Computer Science, Computer Engineering, or a closely related field. The non-tenure track position is primarily a teaching position, requiring as a minimum a Master's degree in a computing or a related degree with computer industry experience. Background and experience in software engineering is desirable. For additional information on the Department of Computing and Mathematics see http://www.erau.db.erau.edu. Daytona Beach is located in East Central Florida, which is a hub for both tourism (Daytona Beach's Speedway, and 34 miles of beach, as well as nearby Kennedy Space Center, Disney World, Sea World, Universal Studios, etc.) and aviation/aerospace activities (Kennedy Space Center, Harris, Boeing, Grumman, Lockheed-Martin, etc.). The combination of mild winters, a relaxed lifestyle and an advanced technological and scientific support system provide an ideal environment for professional and personal enrichment. Applications, including curriculum vitae and the names of at least three references, should be sent, preferably by e-mail, to: =================================================== | Dr. Andrew J. Kornecki, Search Committee | Professor, Department of Computing and Mathematics | Embry Riddle Aeronautical University, Daytona Beach, FL, 32114 | Phone: (904) 226-6888, Fax: (904) 226-6678 | E-mail: korn@erau.db.erau.edu | World Wide Web: http://erau.db.erau.edu/~korn =================================================== ###################################################################### From: Marianne Vakalis Franklin University The Computer Science Program (http://cs.franklin.edu) at Franklin University invites applications for a full-time faculty position. Candidates must have a Ph.D in Computer Science and a demonstrated committment to teaching database and software engineering at both the undergraduate and graduate level. Franklin University is an independent institution serving approximately 5000 students annually. Franklin has a strong commitment to serving non-traditional working students. The University places a premium on excellent teaching, encourages and rewards teamwork, and values faculty who make a contribution to the quality and visibility of programs. The Computer Science faculty pride themselves on staying at the forefront of rapidly developing technologies and strives to bridge the gap between academia and industry. The successful candidate will become an active member of a collegial department. The Computer Science program has approximately 500 undergraduate majors and its recently designed Master's program is pending external approval. Courses and labs are housed in the newly completed Fisher Technology Center. This facility includes computerized classrooms, the Computer Engineering Lab and labs equipped with SUN Ultra and NT workstations. The Computer Science curriculum combines both the pragmatic and theoretical approach to Computer Science in a "learning-by-doing" model that incorporates extensive lab work. For more information see http://cs.franklin.edu. Candidates must include a letter of application (including a statement of teaching interests), a resume, and contact information for three references. Applicants will be reviewed until the position is filled. Send all application materials to: Human Resources Department, Computer Science Faculty Search, Franklin University, 201 South Grant Avenue, Columbus, OH 43215. Questions regarding this position should be e-mailed to Robert Vermilyer at bob@franklin.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE The Forum for Advancing Software engineering Education (FASE) is published on the 15th of each month by the FASE editorial board. Send newsletter articles to one of the editors, preferably by category: Articles pertinent to corporate and government training to Kathy Beckman ; Academic education, and all other categories to Don Bagert . 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). [NEW SUBSCRIBE/UNSCRIBE INFORMATION - September 15, 1998] Everyone that is receiving this is on the FASE mailing list. If you wish to leave this list, write to and, in the text of your message (not the subject line), write: unsubscribe fase To rejoin (or have someone else join) the FASE mailing list, write to 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 and training; CFPs and other such items can still be submitted to the editor for inclusion into FASE. Anyone that belongs to the FASE-TALK mailing list can post to it. FASE-TALK is also used by the editors for "breaking stories" i.e. news that we feel that you would want to hear about before the next issue of FASE comes out. (We do this sparingly, though.) As always, there is no cost for subscribing to either FASE or FASE-TALK! Back issues (dating from the very first issue) can be found on the web (with each Table of Contents) at or through ftp at . The FASE Staff: Don Bagert, P.E. -- Academic/Misc Editor, ListMaster, and Archivist Dept. of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: bagert@ttu.edu Kathy Beckman -- Corporate/Government Editor Computer Data Systems One Curie Ct. Rockville MD 20850 USA Phone: 301-921-7027 Fax: 301-921-1004 Email: Kathy.Beckman@cdsi.com Laurie Werth -- Advisory Committee Taylor Hall 2.124 University of Texas at Austin Austin TX 78712 USA Phone: 512-471-9535 Fax: 512-471-8885 Email: lwerth@cs.utexas.edu Nancy Mead -- Advisory Committee Software Engineering Institute 5000 Forbes Ave. Pittsburgh, PA 15213 USA Phone: 412-268-5756 Fax: 412-268-5758 Email: nrm@sei.cmu.edu