Forum for Advancing Software engineering Education (FASE) Volume 9 Number 05 (112th Issue) - May 15, 1999 831 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents This Month's Topic: Software Process Improvement Education Next Month's Topic: Company-Based Certification Programs Upcoming Topics News Items Working Group on SEE&T - March Meeting Minutes Licensed Software Engineer Named Dean Guidelines for Software Engineering Education - new URL Licensing Articles Calls for Participation CSEE&T 2000 Date Clarification ETCE 2000 Computers in Engineering Symposium Position Openings Umea University, Sweden Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) This Month's Topic: Software Process Improvement Education Software process improvement (SPI) is an essential topic for a software engineering curriculum. Many degree programs have a specific course in software process improvement, while others intersperce it throughout the curriculum. Some SPI courses focus on a particular method (such as ISO 9000), while others discuss several methods. SPI can also be an issue within other software engineering courses. For instance, in a software engineering project course, the project process could be one that undergoes continuous improvement, as it would in an industrial setting. To share their views on software process improvement are three individuals with a variety of backgrounds and points-of-view: Kathy Land, BTG/Delta Research Division Letizia Jaccheri, Norwegian University of Science and Technology Pete Knoke, University of Alaska - Fairbanks As always, we welcome your comments. ###################################################################### From: Kathy Land Software Engineering Training - Software Process Improvement by Default Susan K. Land BTG/Delta Research Divsion Software engineering is a discipline whose aim is the production of fault-free software that satisfies the users needs and that is delivered on time and within budget. Sounds nice, but in order to achieve these goals, appropriate software engineering techniques have to be used in all phases of software production, and maintenance. In order for these techniques to be employed, they have to first be taught. Once in use, they may then be integrated as part of the corporate culture and improved upon. The training provided should enable the definition of a software process that supports sound software engineering principles. Individuals should be trained in the necessary techniques, which facilitate process maturity. The training should be geared toward the perspective of the individuals being trained for it to have the most effect. For example, it does no good to train an entire set of developers in the nuances of Software Quality Assurance (SQA). It is enough that they understand the role of SQA. This article discusses the areas of training emphasis - who, the suggested training - what, and the training methods - how, that can be used to establish a basis for continuing software process improvement. The Team Member All members of the team should be provided training in the applicable life cycle model. This should include the various phases of the software process, from requirements to retirement, paying special attention to problems associated with each phase. This type of training provides all members of the team with a common understanding and clear indication of the road to completion. These individuals should also be provided training in any applicable new technology areas. For example, training in object-oriented design and/or software reuse. All team members should be trained so that they have an understanding of what the Software Engineering Institute (SEI) Capability Maturity Model(R), or CMM(R), is and its goals. They should be knowledgeable in corporate policy and practices. (R)Capability Maturity Model is registered in the U.S. Patent and Trademark Office. (R)CMM is registered in the U.S. Patent and Trademark Office. Those individuals responsible for verification and validation (testing) will require training in the specific techniques to be used during the effort. Training in inspections, walkthrough, and peer reviews should be considered. The Process Lead The individual responsible for each key process area should be provided with detailed training in the CMM(R). This should include an emphasis on available standards such as IEEE, DOD, or Corporate. The issue of how tailoring these standards may impact the success of any attempt at long term process improvement, or affect the outcome of any process improvement assessment must be addressed with the process leads. The leads must be given continuing opportunities to keep current with software engineering methodologies. They must also be provided refresher training for their specific area of leadership. For example, the Software Configuration Lead (SCL) should be offered continuing opportunities in configuration control training and the collection of metrics. Opportunities to evaluate evolving CASE technology must also be provided. The Project Manager All project managers must be expected to continue their education in specific project management (planning, tracking, and controlling) activities. This may include training in estimating and resource management, risk management/mitigation training, and in-depth training in the SEI CMM(R) and the SEI People CMM(R). Possible Training Solutions The idea of reusable technology is a great one; it provides consistency and is cost effective. Videos could be an appropriate solution for team member training. However, this is entirely dependent upon the quality of the videos available for specific training area. Another solution that can provide software engineering/process improvement team member training is interactive computer-based tutorials, these could be hosted via an Intranet and thereby available to all. Mentoring is another positive training solution. If trained individuals exist within the corporate culture, then this gives them the opportunity to both shine and spread their knowledge to their peers. Mentoring can come in the form of lunchtime tutorials, topical briefings at staff meetings, or just-in-time training sessions. Classical software engineering training may also be an option. Many universities currently offer courses in software engineering and specific methodologies. These courses can provide training for both team members and leads. It is important that educational assistance be provided for these opportunities, when they exist. It is important that successful completion of these courses be recognized and tracked. Seminars and conferences provide individuals information on the latest trends and techniques. This type of training is appropriate for those occupying process lead positions or for those sharing in this project responsibility. These opportunities are seen as "benefits" for those acting in leadership roles. They provide opportunities for learning with others in similar leadership positions. It should be a requirement that those attending these types of events share the knowledge gained, thereby benefiting all. Summary The bottom line is that people develop software. Establishing, a software engineering process, and improvement upon that process, depends on the individuals working in an organization. If the individuals are disciplined, and adequately trained in the principles of software engineering, the chances are good that the software process will be successfully defined, implemented, and improved. This, in-turn, increases the probability of achieving the aim of an on time, within budget, error-free software product. ###################################################################### From: Letizia Jaccheri M. Letizia Jaccheri Norwegian University of Science and Technology (This work is partially supported by the Norwegian project SPIQ) A Software Quality and a Software Process Improvement course In 1997, I was asked to re-design and teach a Software Quality and Software Process Improvement course at the Norwegian University of Science and Technology (NTNU). The students who take the course are both 4th year undergraduate students and graduate ones. The course can be chosen by both software engineering students and business and administration ones. My teaching background includes software engineering courses which I have mainly designed and revolve around projects in cooperation with industry [jaccheri-lago97]. Student software engineering background includes a main software engineering course, a project course without external customer, and a project course with external customers. In general, the teaching philosophy at NTNU is based on lectures and mandatory exercises that students deliver during the semester. The problems, when designing the course were: 1. which software quality and process improvement methods and models to choose; 2. how to design the respective exercises. Software engineering topics, in general, and software quality and improvement ones, in particular, cannot be thought in the same way as programming languages or logic. When teaching programming languages, the model can be: teach a construct; show examples; assign exercises; provide solutions, and iterate. This does not work for software process improvement. If, for example, I choose to teach CMM(R), as an improvement model, it takes almost one third of the semester to explain the whole model. Then, it takes again one third of the semester to show an example of CMM(R) use in an organization. And what about the exercises? To be able to design a big exercise that makes the students try on field their knowledge about CMM(R), I need an industrial partner who is willing to let my students work in the organization at quality and process level. This was not acceptable for two reasons: a) students are used to test theories by help of exercises during the semester; b) it was difficult to find organizations who are willing to let the students work in projects at quality and process level (though they are used to assign product-oriented projects to students). I taught the course for the first time in Spring 1998. The main choices were: 1. the book [Humphrey89] as a text book. It has previously been used as the course text book from before, though I could of course change it. One can say that his book is getting old; on the other hand, it is cited by almost each book on process and quality issues and I regard it as a good starting point for people who study process issues for the first time. 2. Four exercises to be assigned during the semester. In the first exercise students are asked to inspect a piece of C++ code (circa 700 lines). In the second exercise, students are asked to test a C++ program against its specification (the source is almost the same size as in the inspection exercise). The third exercise is a modelling one. The students are supposed to model a toy software process by mean of a formal process modelling language. The fourth exercise is designed in a way that the students interact with persons from the local software industry to learn about their process initiatives. In 1998 there were three persons from three Norwegian companies (Statoil, Telenor Novit, and Ericsson Norway). The students were supposed to give presentations and write a report about their understanding of the answers, also in relation with the rest of the course. The external persons gave a talk to answer the following questions: * Why is process improvement important [in your company]? * Which processes does your company have? * Which improvement initiatives does your company implement? * Which relationships exist between software improvement and software quality? Students gave a positive evaluation of the course: the evaluation was higher than the average for all courses and also higher than the course evaluation in previous years. The average of the exam marks is almost the same. My evaluation of the framework was generally positive, and I decided to reuse it for the next year. The problems I had with the framework and for which I decided to implement corrective changes are: three companies are too many and students get a superficial understanding. The first three exercise for which there is no presentations do not receive enough attention. For Spring 1999, I designed the following changes/improvements: A. There is only one company (Ericsson Norway) represented by three persons, the quality manager, the process group leader, and the leader for a project. B. Students are asked to give presentations about all four exercises. C. Concerning the process modelling exercise, the process to be modelled is a fragment of a real process provided by Ericsson. Among the ten groups of students attending the course, five are supposed to use one process modelling language and five another one. This is a starting point toward an evaluation of process modelling languages for software process improvement. D. The questions, which the company actors are supposed to answer, are: * Describe a software system, also by help of quality attributes. * Which processes exist around this system? * Which are the improvement initiatives around these processes? * How general is the software system and the respective improvement initiatives in the general context of the company? A and B can be regarded as corrective changes, while C and D as improvement changes. The modeling of a real process is a more motivating activity than the modeling of a toy process. The process has been explained by an industry person and the students have a certain understanding of how that process is related to the general organization processes. Also the students know that their models will be submitted again to the industry persons. It is also more motivating for me as a teacher to go through students' models when they represent fragments of reality than when they represent toy processes that I have seen modeled several times before. The new questions are better than those used for 1998 as they guide the industry persons to start from a concrete software system and to relate the process and quality issues and initiatives around a concrete example. To sum up, the course is based on this framework: a textbook and some extra lectures that relate the stuff presented in the book with other improvement methods (mainly ISO9000, TQM, and SPIQ which is a Norwegian project) and a set of exercises. The most interesting part of the course is the fourth exercise which is a kind of case study in which actors from the software industry are asked to answer questions in a way they can provide students with real examples. Moreover, students are asked to elaborate such answers in form of presentations and reports. For year 2000 I will reuse the framework again. I plan to tighten the industrial contacts: I will select a piece of real code to be used in the inspection or testing exercise, or in both. I am now in the stage of assessing the text book to use (it may remain the same) and the company to interact with. We are also evaluating some testing tools to be used in the testing exercise. [humphrey89] W. S. Humphrey, Managing The Software Process, Addison-Wesley, SEI Series in Software Engineering, 1989. [jaccheri-lago97] M.L. Jaccheri and P. Lago, "Applying Software Process Modeling and Improvement in Academic Setting", April 1997, Proc. of the 10th ACM IEEE-CS Conference on Software Engineering Education and Training, Virginia Beach. ###################################################################### From: Peter J. Knoke An Evolving Graduate SPI Course Pete Knoke Associate Professor of Computer Science, UAF ffpjk@aurora.alaska.edu 8 May 1999 ------------------------ INTRODUCTION A course, called CS672 - Software Process Improvement, was developed and taught in Spring 1995 at the University of Alaska Fairbanks. It has been taught twice since then, in Spring 1997 and Spring 1999. The 1999 offering has just been completed. All three offerings have been via videoconferencing. This paper gives the rationale for the course, a brief description of its current form, and some related comments. RATIONALE Don Bagert, FASE Academic Editor, posed two questions regarding this topic. * Is an SPI course needed? * How should an SPI course be taught (e.g., standalone or as part of another course, etc)? I developed CS672 to expand the set of Software Engineering-related courses for students in the University of Alaska Fairbanks MS CS/SE program. I believe that studies of both Software Process and Software Process Improvement are key to improving the state of the practice of Software Engineering. Since my students typically know very little about both subjects, I decided to combine them into a single overview course. Perhaps in some program environments the Software Process and SPI material could be integrated with material in other courses. However, given the amount of material presently covered in CS672, and given the nature of its set of its companion SE courses, this integration approach is not now feasible at UAF. So, CS672 will continue as a standalone course for awhile at least. DESCRIPTION A syllabus for CS672, including a summary schedule, follows. ------------------------------------------------------------ ------------------------------------------------------------ SYLLABUS CS672 SOFTWARE PROCESS IMPROVEMENT SPRING 1999 CATALOG DESCRIPTION: Commonly applied methods for improving the software development process. Emphasis on the Software Engineering Institute's Capability Maturity Model(R), or CMM(R), and specifically on the key process areas of Level 2 and Level 3 of that model. These include software configuration management, software quality assurance, and software standards. (Prerequisites: CS 671 or consent of the instructor) KNOWLEDGE: Good understanding of the what, why, and how of widely used software development process principles and methods. SKILLS: Ability to apply principles and methods via exercises in the key process areas of CMM(R) Level 2 and Level 3 (software configuration management, software quality assurance, etc.) Ability to perform some CMM(SM) and PSP(SM)-related exercises. (SM)PSP is a service mark of Carnegie Mellon University INSTRUCTOR: P. KNOKE OFFICE: 208A CHAPMAN PHONE 474-5107 (OFFICE) OFFICE HOURS: 3-6 PM & BY APPOINTMENT 479-2118 (HOME) EMAIL ffpjk@aurora.alaska.edu COURSE STRUCTURE: 13 lectures, 10 homework assignments, 2 exams, and 1 semester project. COURSE TEXTS: 1) "The Capability Maturity Model(R): Guidelines for Improving the Software Process", SEI (several authors),Addison-Wesley, 1995. [ISBN 0-201-54664-7] 2) "Introduction to the Personal Software Process(SM)", Humphrey, Addison Wesley Longman,1997,.[ISBN 0-201-54809-7] (SM)Personal Software Process is a service mark of Carnegie Mellon University COURSE REFERENCES: 1) "SPICE- The Theory and Practice of Software Process Improvement and Capability Determination", El Emam et al. IEEE Computer Society Press, 1998 [ISBN 0-8186-7798-8] 2) "Software Process Improvement: Concepts and Practices", McGuire, Idea Group Publishing, London, 1999. 3) "Software Engineering"(5th ed),Sommerville, Addison-Wesley, 1995. 4) "Software Engineering: A Practitioner's Approach"(4th ed) Pressman, McGraw-Hill, 1997. 5) "A Discipline for Software Engineering", Humphrey, 1995, Addison-Wesley. 6) "Software Process Design: Out of the Tar Pit", Holdsworth, McGraw-Hill, 1994. 7) "Software Engineering Notes" (ACM) 8) "Transactions on Software Engineering" (IEEE) 9) "Software" (IEEE) 10) SPIN (Software Process Improvement Network), WWW (SEI) 11) SEPG Conference materials (e.g. SEPG99 and European SEPG99) GRADE BASIS: Exams 60% (Ex#1, Ex#2, 30% each), Project 30%, Homework 10% --------------------------------------------------------------- BASELINE SCHEDULE FOR SEMESTER COURSE SUBJECT WEEKS 1. Introduction,software process models, software proc imprvmnt 1-2 2. Capability Maturity Model(R) overview (origins, 5 levels)(EX#1) 3 3. CMM(R) Level 2 (Repeatable Process): (Exam#1 review) 4 4. CMM(R) Level 3 (Defined Process) 5 5. Case studies, SPI benefits 6 6. ISO 9001 vs. CMM(R),SPICE Overview, CMM(R) history(CMM(R) 2.0,CMMI)(EX#2) 7 7. Intro to PSP(SM) (part 1) (Exam#2 review) 8 8. Intro to PSP(SM) (part 2) 9 9. Intro to PSP(SM) (part 3), TSP(SM), Selected Other Topics) 10-11 10. Student project presentations 12-13 ---------------------------------------------------------------------- ---------------------------------------------------------------------- (SM)TSP is a service mark of Carnegie Mellon University Project presentations to and from the remote site (Anchorage) were delivered live via videoconferencing. Projects are self-selected with instructor approval, and they are usually done on an individual basis. Some student project titles for Spring 1999 were: "SPI from a Small Business Perspective" "Toni's Software Process" "XXX Receives an Invalid CMM(R) Level" ("XXX" => censored) "PSP(SM) in Practice" "1980 Roots of SPI" "Criticism of CMM(R)" (http://www.weemsworld.com/CS-CMM/) The last mentioned project is of a contrarian nature. It was placed on its author's web site (URL above) where it will remain for awhile (Note: spelling was not a major factor in project grades). COMMENTS * Texts and references As the SPI area becomes more mature, texts and references for this course are increasingly easy to find. The web-based SPIN continues to be very helpful, because it shows SPI to still be very much a grass roots area. SPIN also shows current topics of interest. A new book by Watts Humphrey on TSP(SM), or Team Software Process(SM) might appear soon. (SM)Team Software Process is a service mark of Carnegie Mellon University * Need for "hands-on" student experiences In this course students are sometimes frustrated because they want to do more things "hands on". And, as most teachers agree, this is how the best learning takes place. In CS672 as now constituted, the projects and some PSP(SM)-related homework assignments provide hands on opportunities. However, more are probably needed. * Some recent student suggestions One student suggested that, instead of the subject sequence CMM(R) -> TSP(SM) -> PSP(SM) the sequence PSP(SM) -> TSP(SM) -> CMM(R) might be better. Another student suggested that more emphasis on the ISO9000 area might be desirable. * Masters Projects related to SPI The UAF MS CS/SE program requires each student to do a significant Masters Project (similar to a Masters Theses, but with a few less constraints). So far, three UAF Masters Projects have been completed with their roots in different aspects of SPI. A fourth is now nearly finished. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Next Month's Topic: Company-Based Certification Programs The role of company-based software engineering certification programs, as they relate to licensing issues, are of increasing interest, as engineering license boards in various states and countries consider licensing software engineers as Professional Engineers. [See the "Licensing Articles" section for an example.] One major example of such a certification program in the U.S. leads to the title "Microsoft Certified System Engineer" (MCSE). Such a program allows for a teenager not yet finished secondary education to call themselves an "engineer", unless the state or country outlaws that practice. Licensing is seen as an alternative to certification; however, the companies in question have invested considerable money into these programs, and wish to see them survive and prosper. For this topic, the FASE readership is invited to agree or disagree with the following statement: Graduates of company-based software engineering certification programs should be allowed to use their certification title (e.g. "Microsoft Certified System Engineer"), even if engineers are licensed in their jurisdiction. Please provide an explanation of your answer, and send it to me at by June 8th. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming Topics Sept 1998: Software Engineering Body of Knowledge (Update) Robert Dupuis Pierre Bourque Universite du Quebec a Montreal 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 * Distance Learning * The Relationship Between SE and Other Disciplines 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: Nancy R. Mead Working Group on SEE&T - March Meeting Minutes Working Group on Software Engineering Education and Training Meeting Minutes March 20-21, 1999 Tulane University Stanley Thomas Hall Room 101 Attendees Don Bagert, Kathy Beckman, Jurgen Borstler, David Carter, Jorge Diaz-Herrera, Robert Dupuis, Tom Hilburn, Greg Hislop, Peter Knoke, Jimmy Lawrence, Mike Lutz, Mike McCracken, Jim McDonald, Bill McMillan, Nancy Mead, Susan Mengel, Fernando Naveda, George O. Mary, Cynthia Parish, Dawn Ramsey, Michael Ryan, Laurie Werth Future Meeting Schedule The next meeting will be held in conjunction with FIE in San Juan. Our meeting will be November 9 and half a day the morning of November 10. The FIE Workshops are the afternoon of November 10 and their conference is November 11-13. The FIE organizers will find meeting space for us in the Condado Plaza hotel, the FIE Conference hotel. The subsequent meeting will be in conjunction with CSEET2000 in Austin, Texas. We will meet all day March 5 and the afternoon of March 6, in parallel with the CSEET afternoon workshops. Keynote Speaker Don Bagert of Texas Tech gave an excellent talk on licensing issues, titled "The Licensing of Software Engineers, and Its Effect on Education". Team 1 Industry/University Collaboration Attendees: Kathy Beckman, Jurgen Borstler, David Carter, Jimmy Lawrence, Bill McMillan, Nancy Mead, George O. Mary, Cynthia Parish, Dawn Ramsey George chaired the subgroup meeting and began with a discussion of the completed paper and published Directory. The group decided to do survey in late 97. After few initial responses, the group began an in-depth follow-up. Kathy Beckman helped pull it together in the last quarter. Nancy found there were some emerging types of collaboration not previously recognized (see collaboration models & missions). The survey process included the written survey and interviews. Copies of the instruments are artifacts of the process. Lessons learned from collaborations: Need dedicated industry people Formal meetings will diminish over time Need to carefully define the audience for training Managers must understand and send the right people Need to use some process to evaluate the program Keys to success are continuous feedback and geographic proximity Discussed funding of training. Found employee assistance programs pay for the individuals. But after managers see the value of the training, it is funded out of company rather than being charged to individuals assistance accounts. Discussed difficulty in hiring software engineers Motorola hires technicians and trains them and provide opportunities to earn a BA/S and offer promotions on a pre-set schedule to keep people. Discussed other models and training options. Determined that we may need new sources to get correct collaboration information for the Directory. Future Plans: Distance Learning Investigate delivery mediums format. Content, mix of mechanisms, instructional techniques, how to train instructors to do distance learning (Dawn will pull together some information on this for a report to the group.) Exchange with the European Commission Continue to exchange information Identify common objectives Investigate mechanisms for working together Industry/University Research Collaborations IRUS and GCATT are examples Survey regarding industry needs in software research Survey in software metrics to determine what is really happening in industry Question if there is synergy between education and research in the same institutions. How-To Handbook Sense that collaborations are growing Handbook would include a step-by-step process, case studies, models, how to set up internships, etc. Discussed the purpose and use of the Handbook. Questioned the audience for this information and agreed to survey the participants in the Tuesday program to determine interest). Discussed a dynamic format on the Web with hotlinks. Also mentioned writing a grant to get funding to develop a Web site. Suggested that if we go with this idea we need to explore other associations as well including universities, government agencies, etc. Should we add this information to the Directory rather that doing a separate piece? There is also the concern that we find a way to involve the small and mid-size companies as well. Nancy recommended that we realistically determine what we hope to accomplish and what deliverables we can produce in a 18-24 month time frame. Explained the purpose of the group is to help improve the state of software engineering education. Over the last two years the focus has been on the collaborations. Other outcomes are useful contacts, getting papers published and presenting panels at conferences. In summarizing our future plans, we agreed that we need a strategic view of where we are trying to go as well as a short term plan. After the discussion at the panel presentation we will know more. Also, the group hesitates to start on another project without some market research to determine the need. Discuss local SPIN groups as a source of information. Also, need to determine if such handbook information is already in existence. The model below exemplifies the current status: Audience Resources (existing (E) and potential) ____________________________________________________________________ Professional Societies (SPINS) Directory (E) examples Companies IEEE Software Issues (E) Large paper, examples & model Medium JSS Paper (E) Small Dawn's References (E) University Research Models Faculty Example Research collaborations (E) Administration (group needs to provide some pointers) Students Case Studies (examples FAU, SEFT Government Survey Instruments (E) Local and State Collaboration Models & Missions Federal (in-depth mentor program) Non-profits ____________________________________________________________________ Goal is to think about the content, what exists and what is useful to each audience. The we could list the resources we already have and are contemplating and ask audiences which they need. Suggested actions for getting survey information: All members do individual surveys among groups they know. Need to develop a survey/questionnaire. (Need minutes within two weeks.(mid-April)) Try to approach audiences with this information and determine where there is a match. When you talk to them say - "Are you interested in establishing a collaboration?" Then say -- "Here's what we have - is it valuable - what else do you need?" For those that aren't already involved you may have to define collaboration. Action Items: Collaboration model - Bill will draft and send via e-mail to George by April 16 Minutes out by April 16 via e-mail Nancy and George Informal Information Gathering on needs due in by 5/31 to George Analyze results by 6/30 Develop Questionnaire by 7/31 Use networks to administer Questionnaire by 9/30 Results by 10/15 November WG meeting to determine next step 11/9-10 Team 2: Guidelines for Software Engineering Education Team 2 of the Working Group (the "Guidelines" team) is concerned with study, discussion, activities and proposals concerned with software engineering curriculum design and development. Participants: Don Bagert, Jurgen Borstler, Jorge Diaz-Herrera , Robert Dupuis, Tom Hilburn, Greg Hislop, Peter Knoke, Mike Lutz, Jim McDonald, Susan Mengel, Mike McCracken, Fernando Naveda, Michael Ryan, Laurie Werth 1. The Team discussed the current state of the Guidelines for Software Education and what parts need to be completed. 2. The primary activity of the Team was devoted to the presentation and discussion of draft sample curricula: B.S. in Software Engineering B.S. in Computer Science (with a software engineering concentration) B.S. in Computer Engineering (with a software engineering concentration) B.S. in Information Systems (with a software engineering concentration) a. Ideas and suggestions for revision of each of the curricula were offered b. The team felt it was important to identify and describe, as a part of the curriculum model, profiles of graduates (expected outcomes) of the various SE curricula c. The team decided that the curriculum model should include description of a "common core" of courses/modules that would be part of all SE and SE-related curricula and a description of a set of "key" courses/modules that would be crucial in a B.S. in SE program. 3. The following table outlines the core and key courses/modules for the various curricula. Course Credit Hours Common Key Describe CS 1 (SE 1) 4 X X CS 2 (SE 2) 4 X X Calculus I & Calculus II 3 or 4 each X Discrete Math 3 X X Probability & Statistics 3 X Intro to Software Engineering 4 X X Professionalism and Ethics 3 X X Design & analysis of Algorithms 3 X X Computer Organization 3 X X Technical Communication (written/oral) 3 X Professionalism and Ethics 3 X X Capstone Project 3-6 X X Software Design/Architecture 1-3 X X Software Requirements 1-3 X X Software Quality 1-3 X X Software Construction & 1-3 X X Evolution Computing Fundamentals - 1-3 PL, OS, Comp Arch, DB, etc. 4. The following table outlines work planned through June 1999. Date Deliverable Responsible Party 5/1/99 revise sample for IS - Greg Hislop curriculum for SE, CS, CE, IS CE - Susan Mengel CS - Tom Hilburn SE - Mike Lutz 5/15/99 describe a common core of courses Mike McCracken and modules for the curriculum model 5/15/99 describe a set of key (but not Don Bagert common to all SE -related curricula) courses and modules for the curriculum model 5/15/99 describe the profiles (expect Jorge Diaz-Herrera outcome) for students completing a software engineering degree program 6/1/99 Integrate common core, Tom Hilburn key courses/modules, and sample curricula into the Guidelines. mid-June Meet to review and revise ?? Guidelines and produce a "Version 1.0" document. ###################################################################### By: Don Bagert (Academic/Misc Editor) Licensed Software Engineer Named Dean Earlier this month, William M. Marcy was named Dean of Engineering at Texas Tech University. Dr. Marcy's appointment came after slightly over a year of service as Interim Dean, and an international search by Texas Tech for someone to permanently fill the position. Dr. Marcy is a Professor and former Chair of the Department of Computer Science at Texas Tech. In late 1998, he became one of the first licensed Professional Engineers in the discipline of software engineering in the United States. ###################################################################### From: Tom Hilburn Guidelines for Software Engineering Education - new URL For those of you using access to the "Guidelines for Software Engineering Education" and related material the new address is http://faculty.db.erau.edu/hilburn/se-educ ###################################################################### Licensing Articles The March/April issue of IEEE Software contains an article by Dave Dorchester entitled "Why License Software Engineers?" (pp. 101-104) The May issue of "Engineering Times" contains several items related to software engineering. There is an editorial titled "Software 'Engineer' Controversy" (yes, the word engineer is surrounded by apostrophes); see . There is also a "Viewpoint" article concerning efforts in Pennsylvania to keep people from calling themselves "Microsoft Certified System Engineer" (Also, see the "Next Issue's Topic" section for a related item.) Finally, there were two Letters to the Editor (available online to NSPE members only at ), one of them by FASE Co-Editor Don Bagert. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Don Bagert via Peter J. Knoke CSEE&T 2000 Date Clarification Last issue, the Call for Participation for CSEE&T 2000 was published without an explanation concerning the dates. At CSEE&T 99 in March, the conference dates were announced at March 27-29. However, the dates are now March 6-8 (which is what was published last month). Hopefully this clears up any apparent discrepancies. ###################################################################### From: Stephen Huang Call for Papers ETCE 2000 Computers in Engineering Symposium ---------------------------------------------------------------------- The 22nd International Computers in Engineering Symposium of ETCE 2000 (Energy Sources and Environmental Technology Conference and Exhibition) will take place from February 14 to February 17, 2000 in New Orleans, Louisiana, USA. The conference is organized and sponsored by the Petroleum Division of the ASME, the ACM and the American Petroleum Institute. Papers should present practical experiences as well as scientific research which cover applications of computer science in engineering related fields such as Applied Computing, Database Management, Workgroup Computing, Internet Computing, Project Management Practice, Software Engineering, Quality Assurance. Deadlines: Abstracts (May 31, 1999), Draft Paper (September 15, 1999) and Final Paper (November 1, 1999). For more information, please visit our web site at: http://www.cs.uh.edu/Conference/ETCE. Heinz-Dieter Knoell and Stephen Huang Symposium Co-Chairs ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Jurgen Borstler ASSOCIATE PROFESSOR in COMPUTER SCIENCE Umea University, Sweden The Department of Computing Science invites applications for two positions at the rank of senior lecturer. Appointment is with tenure; the level is roughly equivalent to associate professor in the USA. Both positions require a doctoral degree in computer science, or a closely related area. Umea university is a comprehensive institution of higher learning, enrolling more than 20000 students, and offering undergraduate and graduate degrees in over 80 areas. The Department of Computing Science offers both undergraduate and doctoral degrees, with approximately 400 undergraduate majors and 20 doctoral students. For both positions, a major responsibility will be instruction in one or more core areas of computing science, including networks and data communication, distributed systems, operating systems, architecture, graphics, virtual reality, database systems, high- performance and parallel computing, and theoretical computer science. The positions also involve a substantial commitment to research. For a period of at least three years, the teaching load will be no more than three courses per year, plus direction of undergraduate theses and/or doctoral research. As is customary in the Swedish system, in the longer run, the successful applicant will be expected to pursue salary support for research from external and university sources. For more information, as well as details on how to apply, consult the information contained at the home page of the department, http://www.cs.umu.se/index.eng.html, or else contact the department chairman, Lennart Edblom, edblom@cs.umu.se. For full consideration, applications should be received by May 31, 1999. The starting date for the positions is open and negotiable, but may be as early as October 1, 1999. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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