Forum for Advancing Software engineering Education (FASE) Volume 9 Number 08 (115th Issue) - August 15, 1999 854 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents This Month's Topic: Clients, Students, and Projects Next Month's Topic: The Relationship Between Software Engineering and Other Disciplines Upcoming Topics News Items Guidelines for Software Engineering Education V1.0 Released 1998 CS and SE Education Relevance Survey Results Available Conference Announcements CMM Integration(SM) Transition Meeting Position Openings Southern Polytechnic State University Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Susan Mengel, Guest Editor This Month's Topic: Clients, Students, and Projects GUEST EDITOR: Susan Mengel (CS Prof, TTU) CONTENTS 1) Preface (Susan Mengel) 2) A Course with Service-Oriented Project Work (Vicki L. Almstrum) 3) Using Industrial Sponsors in Software Engineering Courses: A Report from the Front Lines (Paul De Palma) 4) An Experience of Poor Client Relations for an External Project (Alan Jones) 5) Ethics: Some Things That Have Worked (Peter Knoke) 6) Some Recommended Sources (Susan Mengel) ###################################################################### 1) Preface Susan Mengel Assistant Prof of Computer Science Texas Tech University mengel@ttu.edu Thanks to all who contributed to this special topic of FASE. The authors present interesting perspectives on client-based student projects from starting out to client management for student work to ethical instruction. The advice given will help those wishing to incorporate clients expecting a software product into the educational process. The success of Real-World Lab, started by Melody Moore (now at Georgia State University) at Georgia Tech, first sparked my interest in client-based student projects. Having come from industry, Melody wanted to give students a taste of professionalism and software engineering before they were employed after graduation. She and others put an incredible amount of work and energy into developing Real World Lab including the policy and procedure documents which were conveniently placed onto the web for all to see. These documents enabled me to set up my policy and procedure documents quicker than I could have done if I had started from scratch - a real time saver (Another source of policy and procedure documents are the IEEE Standards on Software Engineering, but they can be a little overwhelming with all of the content that they require. They need to be downsized somewhat for student work). As originally set up, Real World Lab is a 3-quarter senior elective sequence where students have to fill out job applications before entering the first quarter. If their application is accepted, they may register for the course and start out as a fledgling worker. If they continue through the other two quarters, they can potentially work their way up to project manager. As they work, they focus on a specific portion of the project. Even in the 3 quarters, they may not see the software to completion, so, others continue the project after them. In order for others to continue, they need the thinking and reasoning of past team members recorded on the web in the form of requirements, design, software, and test documents. These documents mature as the project progresses, but cannot be rewritten every quarter or progress on the project will not be maintained (a real temptation to students to rewrite everything or do nothing with it). As the project nears completion, activities start to focus on commercialization and marketing. For my course, CS 2365 Software Engineering, I could not completely implement the Real World Lab scenario. I only had one semester, the students were sophomores (2 computer science programming classes behind them), and the course was required. I chose to modify the Real World Lab format so that students could work on a part of the project for one semester and leave a legacy behind for the next semester. I also had students put their project materials on the web so that communication among everyone would be facilitated regardless of geographic location. The legacy the students were required to leave behind included project plans, requirements, design, software manual, test plans, and other supporting materials. Students were split into roles, such as project manager, requirements analysts, designers, implementers, and software quality assurance personnel. The project manager role was the most critical and taxing, so, I allowed assistant project managers. With information, such as grade point averages and past experience filled out on the job applications I gave the students, I chose the project managers. This has largely been successful and some project managers in the course have decided to go into management as a result. The students are made to be responsible for the entire project. I function in a supporting role, but make it clear that they are the ones doing the project. They answer to the client and I grade them on the quality of their work (clients are not always experienced technical professionals and may not be able to grade students adequately). The client, however, rates the students at the end of the course for the quality of the work. The students have the entire semester to get the project materials right before I grade them (I grade reviews of their work during the semester to encourage them to keep on schedule). I have also been able to form liaisons with other departments, such as English and Marketing. The English students work on a user analysis and the user's manual while the marketing students perform a marketing analysis for some of the projects. This turned out to be fairly successful although a number of logistical problems cropped up, such as communication among the students. It became clear that the ideal situation would be to have a time when students from all disciplines can meet together, but this was not possible. Instead, email lists were employed and email posted to the web. This was not a complete solution, but helped some. Any advice I could give on setting up courses like this would fill a few volumes, but here are a few things to watch (and definitely know that other professors doing these courses would give some of the same and some different advice). Expect to mentor clients as well as your students during the course. Clients sometimes forget the students are working for them and unwittingly reduce student motivation by not interacting with the students enough. They also may not understand the value in providing the students with pizza, donuts, and pop upon occasion. Have a mechanism for holding students individually accountable for their work even though they need to work in teams so that they can be counseled effectively if they do too much (a real problem believe it or not) or too little (less often a problem). Let the students do the project, not you. Be supportive and help to iron out problems, but let them do the project and get the benefit from it. Do not be their manager, let them manage themselves. Give the students a good background in teamwork and a grievance procedure (in other words, tell them how they should solve problems and give them the option of including you or not). Choose noncritical projects so that students are not placed under unnecessary pressure. There are a number of other issues to address, such as making the students understand the importance of not presenting plagiarized materials on the web as their own work. Definitely include ethics instruction. The client also needs to understand the terms under which the software is produced, such as neither the students, the school, nor the instructor are obligated to work on the software after the semester is over. For more information, please visit http://www.se.cs.ttu.edu and take the projects link to see the project process documents and projects. The project process documents are typically revised in between semesters to streamline the process more and improve the experience for students and clients. ###################################################################### 2) A Course With Service-Oriented Project Work Vicki L. Almstrum Dept of Computer Sciences University of Texas at Austin almstrum@cs.utexas.edu I have been teaching the software engineering class in the CS department at the University of Texas at Austin since Fall 1997. Full information about the course can be viewed via the URL http://www.cs.utexas.edu/users/almstrum/classes/cs373/. The course has two major parts, the theoretical and the practical (a common approach in software engineering). In the practical part of the course, the students are organized into teams of 5 or 6 students and work with an external client to provide a product that the client "orders". The clients are drawn from the Austin community, with a particular orientation toward having the results provide service to the community. Who Are the Clients? The initial pool of clients came from the Young Scientists program, an NSF-sponsored effort that creates science-focused 6th grade classrooms in schools that serve large numbers of minority and low income students. The ultimate goal of the Young Scientists program has been to increase the number of these students entering science-related degree programs at the university level. The director of the program, a personal friend, helped me to make initial contact with the five teachers who were the clients during the Fall 1997 semester. The projects have focused on various mathematical and science concepts that the teachers have requested and several teachers from this program continue to serve as clients. Since Fall 1997, the client base has expanded as others have heard about the work my students are doing. Several teams have done projects for the Dana Center in connection with the Texas Statewide Systemic Initiative (SSI). The SSI is targeted toward providing resources for strengthening mathematics, science, and technology education in local communities (see http://macdns.cc.utexas.edu/ssi/). The initiative is based on the idea of TEKS (Texas Essential Knowledge and Skills). The projects for the Dana Center have been computer interactive or demonstration programs to include among the Clarifying Activities of the SSI Mathematics TEKS Toolkit on the Web. Most of the projects for the Dana Center have been oriented toward high school students, although one project, started in the Fall 1998 semester and enhanced during the Spring 1999 semester, is targeted toward helping young children (ages 4-6) explore the ideas of combinatorics. Child Protective Services (an agency of the State of Texas) was a client during the Spring 1998 semester and has requested that a new team work to expand their project. CPS is responsible for responding to cases where there is suspected child abuse. The software engineering team created a virtual training site for CPS caseworkers, based on an existing MUD. The goal was to create a resource that would allow busy caseworkers to connect remotely via computer to a central site and, interactively and in real time, participate in supplementary casework-related role-playing. The Project Approach I set up the teams fairly early in the semester. During class meetings, the client representatives and I present all of the possible projects. There is then a bidding phase, where each team negotiates internally to select 3 or 4 projects and sketch out a description of the team's proposed approach. The bids are evaluated by the instructor and the TAs (the timeframe is generally too short to involve the clients directly). The quality of the bids is one factor in assigning projects; however, it is also important to spread the projects so that each client has at least one team (and preferably no more than two teams) working for them. I also avoid having two teams work on the same project in a single semester. The team must officially accept or decline the specific project; there can be some negotiation to determine the final assignments. The rest of the project process follows a fairly standard approach. The teams must interview the clients to obtain more details of the projects and to understand the specific environments. The team produces a series of project documents (Software Requirement Specification, Preliminary and Detailed Software Design Specifications, Software Verification and Validation Plan, Software Verification and Validation Report) that capture the appropriate aspects of the design. (I have created customized documentation standards based on industry standards.) During the semester, the teams make three presentations about their work: mid-semester in class: overview of project requirements and team late semester in class: demo of the final product (usually still in unpolished form) end of semester for client: The Client Release Presentation, the (usually) triumphant demonstration of the completed product in the client setting At the end of the semester, the team transfers the frozen product into the instructor's product repository and turns in a notebook that includes the final versions of all documents and code. Monitoring Team Status I have several mechanisms in place that help me monitor the teams' projects. First, each individual student completes a journal entry about every other week. The journal entries include both academic and project- oriented questions. The project-oriented questions allow me to gain some insights into how the projects are proceeding. Second, each team completes several team reports during the semester. These reports give me information about what the teams are up to. The team report also acts as a prod to help encourage procrastinating teams to get a start on activities such as establishing configuration management. Third, the TAs are responsible for completing project audits twice during the semester. In these audits, the TAs are to ensure that each team's directory structure is set up correctly, that the content of the directories is complete, and that other administrative aspects have been set up properly. (The audits have sometimes been a weak link, since some TAs have been too inexperienced or paid too little attention to do a good job at the audit.) Fourth, a mentoring program with external mentors has provided each team with one or two mentors from industry. The job of the mentor is to help advise the team and monitor where they may be having problems. The procedures for this program are still under development, since it has only been run for "real" one semester. Legal And Practical Aspects There is a number of legal and practical questions that a project of this magnitude must face. I am currently in the process of working with legal representatives for the University of Texas System to ensure that the projects and students are properly protected. All projects have been put under copyleft (Free Software Foundation); independent study students are helping me resolve the details of how to retrofit the appropriate notices even as I write this. The products are currently available on the Web (although there is still some work required to complete some of the products). I have students working on an interface that will provide a better approach to using the site. We plan to create CDs with the "released" products, which will be distributed to our client teachers and their clients. A vision for these products is that future software engineering teams, both at the University of Texas at Austin and at other institutions, will enhance and improve them. The Challenges For The Future This course and the project work have been an exciting ride thus far. The department and I plan for me to continue to offer the course in this format for the foreseeable future. The main challenge at the moment is to complete the administrative work to ensure that the legal aspects are set up properly. ###################################################################### 3) Using Industrial Sponsors in Software Engineering Courses: A Report from the Front Lines Paul De Palma Mathematics and Computer Science Gonzaga University depalma@gonzaga.edu Abstract It has become increasingly popular among departments of computer science as well as in schools of engineering to require a year-long design course. In courses like these, industrial sponsors provide ideas for systems that teams of students then design and implement. There are many subtle issues that creep into such courses. Two important ones that I address are the ambiguous role of the professor and the crowding out of theory for practice. Report I have just finished my first pass through our two semester software engineering sequence, CPSC 491 and CPSC 492. Since my struggles (and successes) are still fresh in mind, I would like to offer some reflections on our use of projects solicited from the computer industry. Though the students enjoyed the course, and I think their efforts made them more employable, two issues naturally arise, one with 491, a conventional survey of software engineering methods, the other with 492, a team-based approach to the design and implementation of projects that we get from industrial sponsors. I will address each in turn. Our first semester, CPSC 491, is a valuable course and, with modifications to ground it in the real world, should remain part of our offerings. It is useful for students to see that there are many approaches to large-scale software design. In fact, it comes as something of a revelation to them--since they spend so many red-eyed hours in front of a screen--that software is designed at all. I propose that the course continue to be a survey of software engineering techniques supplemented with a major team project. This team project would be the development of standard design documents (requirements definition, architectural specifications, system specifications) for projects submitted by computer industry sponsors. Design is the really important aspect of the software engineering: how to clarify what a client wants when the client himself is not clear; how to design a system so that seat-of-the-pants coding is replaced with engineering; how to design a system that will be maintainable for its projected life; how to project the allocation of resources into the future, and much, much more. Coding is secondary. Computer students are typically willing to spend hour after hour in front of a screen. We don't need to re-enforce that willingness. What they are not willing to do is to design before they begin to code. This is a discipline that we should teach. Our present model, wherein the sponsor supplies a liaison engineer who serves as a first-level manager, has several flaws. I propose changing the role of the sponsor from manager to client. To begin, in its present form, the role of the professor is ambiguous. The natural tendency, and the one I began with, is to act as a second-level manager. This gives authority in the course the tree structure found in all businesses. Thus each team reports to a liaison engineer supplied by a corporate sponsor. The liaison engineer reports to the professor. Unfortunately, this does not describe our situation. The liaison engineers, of course, did not report to me. In practice, this meant that my attempts to oversee design issues meant that my students had two masters, me as well as their liaison engineer. To make this more concrete, here is a small, but typical conflict. I directed my students to use data flow diagrams to model the flow of data throughout their systems. Now, we had previously studied other design methodologies, but I knew from a decade's experience in the computer industry that data flow diagrams would work. For two of the three projects, however, the liaison engineers wanted their teams to use a different approach. Though this is fine, it meant that I had to step back and let the liaison engineers take over. You can see that this reporting structure is more complex: each team reports to both me and to the liaison engineer. Now, no business that I am familiar with uses this kind of reporting structure for that same reason that most object-oriented programming languages do not permit multiple inheritance. Namely, it introduces ambiguity. I spent six of the most frustrating months of my working life as a systems analyst at a large university that had exactly this kind of dual-reporting structure. I took the job only so that I could work on a graduate degree in computer science. I soon learned that no degree in the world was worth reporting to both the registrar and the director of computer systems. Who was it who said that one cannot serve two masters? This is exactly what we have been asking students to do. The way our sequence is currently constituted, students begin gathering requirements and working up a design just after the middle of the first semester. In theory, when they return from Christmas break, they will have a set of software specifications that they can use to begin coding. The coding is supposed to last until just after the midterm when they begin module and integration testing. In arguing for this course a few years ago, we said that we would offer our students an opportunity to apply what they have learned to a large project in a business setting. Having observed this course intimately, I now ask these questions: isn't applying what students have learned to a large project in a business setting exactly what they would do on their first job? And are we not, in effect, asking students to pay for training that has traditionally been supplied by business? Now, I can hear it being argued that students gain "real- world" experience from working on business projects and that this experience makes them more marketable. Indeed they do, and indeed it does. But again, they learn nothing in CPSC 492, in coding and testing their design, that they would not learn in their first six months on their first job. In fact, since their attention is divided between CPSC 492 and the other demands/pleasures of being seniors, they learn considerably less. CPSC 492 amounts to a kind of scaled- down internship. Most computer science programs, ours included, already have internships on the books. In fact, requiring CPSC 492 as we do precludes a course in those areas that one can study intensively only in a university. Our current CPSC 492 included seniors who somehow managed to graduate without courses in operating systems, database management systems, or communications, or compilers, or computational theory. One of these insisted that the smattering of Microsoft Access he picked up while doing his project was the equivalent of a DBMS course. This is utter nonsense, of course, and underscores just how badly informed some computer science graduates, with their built-in tendency towards the nuts and bolts of industry, can be. Another told me that he was thinking of leaving our program because we do not offer course work in Windows programming. Another concurred, saying that we could not continue to call ourselves a computer science department without courses in Microsoft's proprietary products. This is like asking the Art department to offer coursework not in painting and design but, rather, in the specific properties of Liquitex acrylics. The point I am trying to make here is that the point computer science professors have been making since our discipline emerged forty years ago. We teach principles. It is up to industry to teach proprietary products. CPSC 492 obscures this fundamental fact. There is a further pedagogical problem with CPSC 492 and other in- house internships. Namely, the liaison engineers, though all skilled, enthusiastic, and well intended, simply did not have the time to oversee the projects as closely as industry project leaders would have. That is, though CPSC 492 is billed as a taste of the real world, in fact, students are supervised much less closely than new employees in firms that I am familiar with. Of the three projects that my students worked on, the most successful had the most involved liaison engineer, the least successful the least involved. This is not a criticism of our sponsors. The liaison engineers were, to a man, generous, concerned, and skilled. The problem is structural. They simply were not on-site, and so were not available, in the way that a manager in business is available to his/her team. Nevertheless, it is precisely this close mentoring, typically given to new employees, that transforms the student into a software developer. It may be argued that it is up to the professor to provide that day- to-day guidance on projects. This past semester I did meet with each team regularly. Nevertheless, due to the dual-reporting structure mentioned above, I was reduced to something like a personnel manager. That is, I asked the teams to set weekly goals in writing, asked them to account for goals unmet, tried to resolve conflicts, procured needed resources, and served as an intermediary between the team and their liaison engineers. What I could not do--because authority over design belonged to the liaison engineer--was criticize the design, set the milestones or participate in the day-to-day issues of getting the products out the door. In effect, I was a second-level manager without authority. This was frustrating, because the success or failure of the course depended on aspects over which I had almost no control. Given my year-long experience, I offer these proposals to colleagues considering setting up a similar program: Proposal A Provide a single semester course in software engineering that surveys software engineering principles for seven to ten weeks. Gather projects from the computer industry, but transform industrial sponsors from project managers into clients. Students, in teams, would spend the balance of the semester experimenting with one or more design methodologies on a project of substantial complexity. The final product will be sets of specifications and the beginnings of system and user documentation. Proposal B Provide a two-semester sequence in software engineering. The first semester would be as described in Proposal A but with a greatly expanded role for corporate sponsors. Students would implement the system in the second semester that they designed in the first, again with a greatly expanded role for the corporate sponsor. For instance, as a requirement of sponsorship, the companies involved should free up an employee to meet weekly with students and to, at minimum, do biweekly code and design reviews. Though I think this would be an improvement over the sequence as presently constituted, it does not resolve the dual-reporting structure. Therefore, I recommend that liaison engineers be given complete authority over the projects since they have de facto authority anyway. The liaison engineers could then provide biweekly status reports to the professor. Using computer industry-solicited projects in a software engineering course is quite appealing. The bulk of our students, after all, go directly into the computer industry. Nevertheless, there are subtle problems that are built-in to this model. My proposals address the most striking problems that I encountered. ###################################################################### 4) An Experience of Poor Client Relations for an External Project. Alan Jones University of Teesside School of Computing and Mathematics Alan.Jones@Tees.ac.uk Looking for a contribution from our fairly long experience of setting up external projects for postgraduate and undergraduate software engineering students, it seems that the issue of management responsibility and client relationship management is the area we have found most problematic. External projects have been a feature of postgraduate Masters programmes at Teesside since 1990. We have many satisfied clients around UK, most notably British Telecom (BT) who set up a 'preferred status relationship with software engineering graduate students from Teesside in the early and middle 1990s. We adopted many 'contract management' procedures, perhaps most notably a simple review mechanism for assuring that the project specification met both the client's and the University's quality criteria. Overlooked, because it then presented no difficulties, was the area of client relationship management during the project. This problem surfaced seriously when these projects with external clients were emphasised by University management as an area for income generation. In retrospect, the previous integrity of the process was lost. Instead of being wholly focused on academic and engineering aims, it became targeted on achieving a certain level of income from all external client projects. While quality assurance remained in place for postgraduate projects, no similar mechanism existed for undergraduate projects. There was no management linkage between procuring the project, academic supervision of the student, and assuring the expectation of the client. This problem surfaced when income targets were not reached. On internal enquiry, debt chasing by the accounts department had stalled in the face of client hostility. Enquiry by a member of academic staff then had to cover a long period of dissatisfaction from the unhappy client. The root cause was non-delivery of promised software-related product to client by student. This was not uncovered until six months after due delivery date. This happened two years ago. Relations with that particular client are still not easy. Plans are now in hand to approve a set of client relationship management procedures. But it remains that clients who engage with student projects usually have some commercial objective, however much it has been watered-down to permit limited time and resource typical of student projects. Non-achievement of that objective creates unhappy clients who are unwilling to engage in further projects. ###################################################################### 5) Ethics: Some Things That Have Worked Pete Knoke Computer Science University of Alaska Fairbanks ffpjk@uaf.edu For about the last 17 years at University of Alaska Fairbanks, there has been a required senior capstone course in which student teams do real software development projects for real customers under realistic conditions (including cost and schedule constraints). The course, which slowly evolves, has been quite successful over the years. Projects are typically done by 5-student teams. Over the last 11 years, 28 consecutive projects have been completed successfully. "Success" means that the customer awards the student team a grade of at least A or B+ for their development. Usually the customers are external; i.e., from outside the university. Also, usually the customers are different each year. The capstone course described above is overloaded because it must be oral-intensive (lots of presentations) and writing intensive (lots of technical writing). It includes an overview of Software Engineering methods and practices. It must also include computer and software related ethics (a requirement of CSAB accreditation). Because of the course overloading, only 8-10 hours of class time are available for the topics of software-related ethics and law (intellectual property law, etc.) The approach to ethics/law that I now use and that seems to succeed has the following main ingredients: 1) Review a number of ethics codes with most emphasis on Gotterbarn & co. code which has been recently approved. All of these are available on the web. 2) Review summaries of computer-related law (intellectual property law, contract law, anti-trust law, etc.) Over the past few years I've liked a summary by Kay (which was published in FASE several months ago). However, many good articles on computer-related law can be found in technical journals such as ACM Communications, IEEE Micro, etc. 3) Keep an eye open for current related materials from such sources as the Wall Street Journal and the New York Times, and provide the materials to the class (this is especially easy because both sources are available on-line). 4) Encourage student thought about these ethics/law issues by basing open-book open notes exams on these subjects. 5) Encourage student thought about these ethics/law issues by basing exam questions on how these issues relate to the particular real software development project that the student is working on. I've been surprised and pleased by how well this approach has worked. For example, in an exam in Spring 1999, I asked students to review a Parnas-Gatterbarn debate on the benefits of the Gatterbarn SE code, and was surprised to see that most students tended to agree with Gotterbarn (Parnas didn't see great benefits in the code, as I recall. If anyone is interested in that particular reference, I think I can search and find it if you ask by email). I might add that I have become a little cynical as I get older, and the experience of hearing thoughtful, fresh and uncynical opinions on these subjects from young people has been quite uplifting for me. ###################################################################### 6) Some Recommended Sources T.M. Beheler and J. Malar. "Student Collaboration: The Ups and Downs of a Real Life Project." Proceedings of the 42nd Annual Conference of the Society for Technical Communication. Arlington, VA: STC, 1995, pp. 87-90. Codes of Conduct/Practice/Ethics from around the world, http://ei.cs.vt.edu/~cs3604/lib/WorldCodes/WorldCodes.html. P.J. Denning. "Educating a New Engineer." Communications of the ACM, vol. 35, no. 12, December 1992, pp. 83-97. Holcombe, Stratton, Fincher and Griffiths (eds). Projects in the Computing Curriculum, Proceedings of the Projects 98 Workshop. Springer-Verlag, 1998, ISBN 1-85233-010-4 (with thanks to Dan Simpson, University of Brighton for submitting this reference) W.B. McCarty and G.T. Plew. "How Mature is Your Software Process?" J.L. Diaz-Herrera, ed., Proceedings of Seventh Conference on Software Engineering Education, New York, NY: Springer-Verlag, 1994, pp. 555- 564. M. Moore and T. Brennan. "Process Improvement in the Classroom." R.L. Ibrahim, ed., Proceedings of Eighth Conference on Software Engineering Education, New York, NY: Springer-Verlag, 1995, pp. 123-130. M. Moore and C. Potts. "Learning by Doing: Goals and Experiences of Two Software Engineering Project Courses." J.L. Diaz-Herrera, ed., Proceedings of Seventh Conference on Software Engineering Education, New York, NY: Springer-Verlag, 1994, pp. 151-164. Online Ethics Center for Engineering and Science. http://www.cwru.edu/affil/wwwethics, specifically for instruction with other links of interest. Real World Lab, Georgia Institute of Technology, http:// www.cc.gatech.edu/classes/RWL/Web/. Software Engineering Code of Ethics and Professional Practice (Version 5.2) as recommended by the IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices, http://www.computer.org/tab/swecc/code.htm. S.H. Unger (moderator) and W. Sweet (editor). "Ethics Roundtable: Doing the Right Thing." IEEE Spectrum, vol. 33, no. 12, December 1996, pp. 25-32. Web Clearinghouse for Engineering and Computing Ethics, http://www4.ncsu.edu/unity/users/j/jherkert/ethicind.html. L.H. Werth. "An Adventure in Software Process Improvement." J.L. Diaz-Herrera, ed., Proceedings of Seventh Conference on Software Engineering Education, New York, NY: Springer-Verlag, 1994, pp. 191- 210. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Next Month's Topic: Software Engineering Body of Knowledge (Update): The Relationship Between Software Engineering and Other Disciplines Guest Editors: Robert Dupuis Pierre Bourque Universite du Quebec a Montreal The guest editors have offered themselves as co-editors of the September issue on the topic of the relationship of between software engineering and other disciplines. This is of course an important issue for the Guide to the SWEBOK project and one on which they have worked on in the past and on which the 10 "knowledge area specialists" of the SWEBOK project (see FASE, March 1999) are currently pursuing. If you wish to contribute to this issue, please contact the guest editors at the addresses above. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ October 1999 Topic: Distance Learning and Internet Education Guest Editors: Joe Kasser, University of Maryland University College (UMUC) A Rajagopal, Tata Infotech Limited Bruce Schafer, Oregon College of Engineering and Computer Science Ahmed Seffah, Centre de recherche informatique de Montreal (CRIM) Call for Participation The October 1999 Issue of FASE will be feature articles on "Distance Learning and Internet Education." Many working software engineers find it impossible or very inconvenient to travel to traditional campuses to take courses in software engineering. For many years microwave and satellite video delivery have provided an important option to these place-bound students. More recently, the Internet has opened up new opportunities for distance learning including the ability for the student to choose both the time and place where they will participate in course work. The October 1999 issue of FASE will feature a set of articles on this subject. Joe Kasser, A Rajagopal, Bruce Schafer, and Ahmed Seffah will serve as co-editors of this issue. Please take a few minutes to write up your thoughts and experiences as they apply to software engineering and training at a distance and email them to Ahmed Seffah by September 7, 1999. If you have questions, please contact Bruce Schafer . ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming Topics Dec 1999: A special millennium-ending topic will be announced in the September issue. 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. If you are interested in being a guest editor, or have any suggestions for future topics, please contact me at bagert@ttu.edu. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### From: Tom Hilburn Guidelines for Software Engineering Education Version 1.0 Released 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 been 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. The first complete version of the Guidelines has just been completed. They 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://faculty.db.erau.edu/hilburn/se-educ). The WGSEET encourages and solicits comments on the Guidelines (send comments to hilburn@db.erau.edu). Tom Hilburn Department of Computing and Mathematics Embry-Riddle Aeronautical University hilburn@db.erau.edu ###################################################################### From: Tim Lethbridge 1998 CS and SE Education Relevance Survey Results Available The final results of the 1998 Computer Science and Software Engineering Education Relevance Survey are now complete! This survey, conducted from May to October 1998, collected data from about 200 software engineers and managers from several countries. The goals of the research were to gather data that would be of use to those designing, improving and accrediting academic programs in software engineering, as well as to those training software engineers who are already practicing in industry. The participants were asked four questions about each of 75 topics that they might have studied in their formal education, or learned later on the job. The questions asked 1) What they had learned in their formal education about the topic; 2) What they know now about each topic; 3) How important the details of each topic has been to them; and 4) How influential the topic has been to their lives. You can view the web-site at http://www.site.uottawa.ca/~tcl/edrel/ This site contains: - A complete technical report with the results (in several formats) - Summaries of the key results - A spreadsheet that you can use to perform other analyses - Other links to software engineering education This research was conducted by Timothy C. Lethbridge at the University of Ottawa, and assisted by the Consortium for Software Engineering Research (CSER), Nancy Mead, W. Michael McCracken, Laurie Werth, Lawrence West, Michael Lutz and Pearl Brereton. Timothy C. Lethbridge, | Assistant Professor / Professeur adjoint http://www.site.uottawa.ca/~tcl | tcl@site.uottawa.ca/T.Lethbridge@ieee.ca SITE: School of Information Technology and Engineering University of/d'Ottawa | W/B: 613 562-5800 x6685 Ottawa, Canada, K1N 6N5 | Fax: 613 562-5187 H/M: 613 237-6642 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Conference Announcements ###################################################################### From: Judy A. Vernick CMM Integration(SM) Transition Meeting CMMI(SM)-SE/SW Version 0.2 will be released for public review on August 30, 1999 at the SEI 99 Software Engineering Symposium. A tutorial on this model will be held at Symposium on August 30th, and an entire Symposium Track will be devoted to CMMI presentations on Tuesday, August 31st. The SEI is seeking community assistance and involvement in the introduction and adoption of this new technology. You are invited to attend a special meeting at the SEI on Friday, September 3, 1999 for additional, in-depth, presentations on CMMI-SE/SW Version 0.2, and to learn about opportunities for becoming an SEI Transition Partner for the associated model training and assessment services. The meeting will be held at the SEI in the Auditorium from 9:00am to 3:00pm. There is no charge to attend this meeting. Beverages will be provided during morning and afternoon breaks. Lunch will be on your own. Attached is the Agenda for this meeting. Please contact SEI Events for registration information: registration@sei.cmu.edu If you cannot attend this meeting but would like information about becoming an SEI Transition Partner for CMMI products and services, please contact: SEI Customer Relations phone/fax: 412 268 5800 e-mail: customer-relations@sei.cmu.edu Agenda 9:00am - 9:30am Welcome and Background 9:30am - 12:00pm CMMI Presentation & Discussion 12:00 - 1:00pm Lunch on your own 1:00pm - 2:00pm SEI Transition Partner Program for CMMI 2:00pm - 3:00pm Open Q&A (SM)CMM Integration and CMMI are service marks of Carnegie Mellon University. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Position Openings ###################################################################### From: Jorge L. Diaz-Herrera VISITING FACULTY POSITIONS Southern Polytechnic State University, Department of Computer Science Southern Polytechnic State University, Marietta, GA, Department of Computer Science, is seeking several one-year visiting Assistant/Associate Professor and/or Instructor positions beginning Fall,1999. The Assistant/Associate Professor positions require the Ph.D. in computer science or a closely related field; Instructor positions require a Master's degree with a minimum of 18 graduate hours in Computer Science. Effective teaching ability in typical CS curriculum is required for all positions. Ability to teach graduate courses in our MS programs is required for Assistant/Associate professor positions. Most desirable area of interest is Software Engineering, including object-oriented development, component-based computing, requirements engineering, software design and architectures, testing and quality assurance, and process improvement; other areas of interest are theory of computation, operating systems, system programming, interactive systems and multimedia. Southern Polytechnic is a state university in the University of System Georgia located approximately 15 miles north of Atlanta. SPSU is primarily a teaching institution with activities in applied research, distance learning, and industry related projects. We are currently involved in a state-wide initiative involving embedded and distributed computing and systems-on-a-chip (http://www.gcatt.gatech.edu/yamacraw). The CS department, the largest of the University with 700+ undergraduate and 300+ graduate students, offers BA, BS, and MS degrees in CS, the MS degree in Software Engineering, and certificates in Programming and Software Engineering. The department computing facilities include workstations and/or PC's in faculty offices, faculty research laboratories, and student Unix and PC laboratories. Qualified applicants should send a letter of interest, vita including three references, and unofficial transcripts of all university-level work. Screening of applications begins as they are received and continues until the positions are filled. Please send applications to Dr. Jorge L. Diaz-Herrera, Head, Department of Computer Science, Southern Polytechnic State University, 1100 South Marietta Parkway, Marietta, GA 30060-2896. Internet: jdiaz@spsu.edu, http://www.spsu.edu/cs/cs.html. Phone: 770-528-7406. Fax: 770-528-5511. SPSU is an AA/EO employer. Minorities and women are encouraged to apply. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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: kbeckman1@erols.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